Ainsi, pour un néophyte en programmation, la gestion du temps est par exemple une chose très simple, puisqu’il y a des secondes, des minutes, des heures, des jours et que tout cela mis bout à bout permet d’obtenir des années, des siècles et même des millénaires.

Et de plus, tout cela est régi par des règles universelles, car tout le monde sait que 60 secondes forment une minute, que 60 minutes forment une heure et que 24 heures constituent une journée.

Le tout est de plus utilisé quotidiennement de manière quasi automatique par le commun des mortels depuis plusieurs millénaires, et si le commun des mortels est capable de le faire, un ordinateur devrait en être tout autant capable.

Sauf qu’en réalité, le temps et sa gestion sont infiniment plus complexes, car pour paraphraser Albert Einstein, il s’agit d’une notion toute relative.

Toutes les années ne font en effet pas 365 jours, comme tout les mois ne font pas forcément 30 ou 31 jours et certaines journées peuvent faire 25 heures, voir même contenir des secondes intercalaires.

De plus, en fonction de la position géographique, une date n’a pas forcément la même signification, puisque le 14 février à 18 h en France peut être le 15 février à 2 h à Tokyo.

La représentation d’une date peut également prendre moult formes, en fonction de la langue, du calendrier, de l’époque ou de la culture utilisée, ce qui peut par exemple mener à des ambiguïtés si le référentiel n’est pas précisé.

Ainsi, 9 h peut tout aussi bien signifier 9 h ou bien 21 h.

De plus, une date pourra avoir une signification différente en fonction de l’ordinateur utilisé, grâce par exemple à la magie de la localisation.

Le développeur doit donc prendre tout cela en compte, et même si les règles sont bien connues, faire les bons choix techniques en fonction du contexte d’utilisation et prendre en compte ces règles pour répondre correctement à un besoin peut devenir une véritable gageure.

Et si d’aventure les règles relatives au métier sont également complexes, la problématique peut devenir rapidement très complexe, et si vous avez le moindre doute à ce sujet, je vous invite pour vous en convaincre définitivement à, par exemple, lire les textes de loi régissant les 35 heures ou bien encore les congés payés.

J’ajoute que pour couronner le tout, valider le bon fonctionnement d’un code utilisant le temps peut être délicat, puisqu’il faut pour cela pouvoir se mettre aussi bien dans des contextes d’utilisation nominaux, mais aussi dans des contextes d’utilisation particuliers, par exemple un passage de l’heure d’hivers à l’heure d’été.

Or, la machine à voyager dans le temps n’a pas encore été inventée et s’il est bien possible d’avancer ou de reculer l’horloge d’un ordinateur à volonté, c’est une démarche plus que fastidieuse à réaliser dans le cadre du test logiciel, sans compter que cette modification peut avoir un impact significatif sur le bon fonctionnement de la machine.

Tester le comportement d’un code utilisant une ou plusieurs données temporelles demande donc des techniques d’ingénierie logicielles spécifiques, par exemple la mise en œuvre de bouchons permettant de simuler de manière logicielle l’écoulement du temps au niveau des tests unitaires.

Le développeur peut alors à sa guise accélérer le temps, le ralentir ou s’y déplacer, ce qui lui permet de valider son code par rapport à toutes les situations qu’il peut imaginer.

Reste que le développeur restera tout de même un Humain, et qu’en conséquence, il est sujet à l’erreur et qu’il est très possible que malgré ses efforts, un cas limite lui échappe et que malgré les tests, un bug restera donc tout de même caché au sein de son code, n’attendant que le moment adéquat pour se manifester.

Or, le néophyte ne voit rien de tout cela, et c’est absolument normal, car outre le fait que l’informatique moderne est conçue de façon à masquer totalement sa complexité à son utilisateur final, ce dernier n’a pas à la connaître car ce n’est pas son domaine d’expertise.

Et ce qui est valable pour le temps s’applique également à la sauvegarde dans un fichier, aux connexions à une base de données, et même parfois à des calculs très basiques.

Durant ma première expérience professionnelle, j’ai ainsi eu besoin de justifier le développement d’un programme en C au lieu d’un code en PHP pour calculer des proratas, car mon interlocuteur n’arrivait pas à comprendre que PHP était un outil particulièrement inefficace pour effectuer des calculs même très simples avec des flottants.

D’ailleurs, je ne parlerais pas de la problématique posée par les arrondis qui parait souvent totalement aberrante au béotien tant il a une perception absolue de l’informatique, à tel point qu’il ne veut pas comprendre que pour un ordinateur 0.33333 + 0.33333 n’est pas égal à 2/3 et qu’en conséquence, faire calculer une TVA ou un total de facture à un ordinateur n’est pas forcément une chose simple.

Tout cela pour dire qu’il peut être pertinent lors d’une discussion à propos d’un chiffrage ou d’une planification de faire preuve de pédagogie en donnant une idée, même minimale ou approximative, de la complexité des problèmes à résoudre au niveau informatique pour obtenir le résultat désiré.

Et pour y parvenir, je n’ai toujours pas trouvé la recette magique, donc si vous avez des suggestions, n’hésitez surtout pas à me la communiquer, car je saurais quoi en faire quasi quotidiennement.