Tout d’abord, si ces gens pensent manipuler correctement et facilement un concept tels que le temps, c’est en fait très rarement le cas.

Si vous voulez vous en convaincre, il vous suffit de demander à quelqu’un de vous dire par exemple si le prochain mois compte bien 30 jours, ou si le prochain mois de février aura 27, 28 ou 28 jours, ou bien de vous donner l’heure qu’il sera dans 940 minutes, ou bien si le 24 décembre sera l’année prochaine un samedi ou un mercredi.

Vous constaterez alors que bien peu de gens sont capables de répondre à ce genre de question rapidement et surtout sans faire d’erreurs.

Or, en informatique, les erreurs existent également et l’ordinateur doit être capable de plus ou moins les gérer en fonction de la criticité des tâches qu’il effectue.

Et le panel des erreurs possibles est très vaste, car si l’Homme est généralement très faillible lorsqu’il effectue un calcul mathématique, l’ordinateur doit lui faire face à des erreurs de nature bien plus différente et variée.

En effet, si les probabilités qu’un calcul effectué par un ordinateur soit incorrect mathématiquement parlant sont extrêmement faibles (mais pas non nulle), techniquement, un grand nombre de problèmes sont susceptibles de survenir au cours de l’exécution d’un programme.

La connexion réseau peut être interrompue, un composant peut devenir défectueux, la mémoire de masse ou la mémoire vive peuvent ne pas être disponibles en quantité suffisante pour la bonne exécution du programme, ou plus simplement, le système d’exploitation ou l’un de ses services peut être mal configuré, un fichier peut être inaccessible car l‘utilisateur ne dispose pas des permissions nécessaires, et cette liste est loin d’être exhaustive.

Un (bon) développeur doit en effet lorsqu’il développe un programme se préoccuper de la disponibilité des ressources que ce dernier utilise au niveau matériel et logiciel.

Mais cela, le néophyte l’ignore totalement, car il a tendance à penser dans un premier temps que l’informatique est une technologie infaillible, malgré les années d’éducation données par Microsoft à ce sujet avec ses « Blue Screen Of Death »…

bsod.png

Or, la gestion des erreurs est une tâche difficile et parfois extrêmement complexe pour un développeur, car en fonction du type des erreurs susceptibles de se produire et de leur contexte, il devra définir des stratégies permettant au programme à minima de se terminer correctement et à maxima de poursuive son exécution soit dans un mode dégradé, soit comme si de rien n’était.

Et je ne parle même pas de la difficulté qu’il peut avoir à tester les différents cas d’erreur possibles au niveau unitaire avec l’aide de bouchons et autres moles.

Il n’est donc pas rare que la gestion des erreurs demande au développeur un travail largement plus conséquent que celui requis par le développement de la tâche que doit réaliser son programme lorsque tout se passe bien, que ce soit en terme de volume de code ou bien en terme de conception et de tests.

De plus, dans un monde idéal, il faudrait que le programme conserve une trace de ces erreurs, afin de permettre aux développeurs ou aux administrateurs systèmes d’être alerté et pouvoir ainsi prendre rapidement et efficacement les mesures correctives adéquates.

Et là encore, un grand nombre de stratégies sont possibles, en fonction de la criticité du programme et donc du niveau de précision désiré.

Une personne n’ayant aucune idée de ces problématiques peut donc penser qu’un développement est très simple et va donc être réalisé très rapidement, vu qu’elle fait totalement abstraction de la partie la plus délicate du travail à effectuer puisqu’elle en ignore l’existence.

Et si d’aventure l’envie vous prend de lui en parler, je suis prêt à parier qu’elle vous répondra que tout cela n’arrivera jamais, même si la Loi de Murphy est démontrée quotidiennement.