Aux sources de l’informatique, il y a l’erreur humaine

Pourquoi automatiser ?

En premier lieu, on répond parce que l’erreur est humaine. Cette notion est tellement ancienne qu’on se souvient encore de sa forme latine : errare humanum est.
La suite de cette locution latine « perseverare diabolicum » (persévérer [dans son erreur] est diabolique) devrait nous inciter à automatiser au plus tôt. Nous y reviendrons.

Retour aux sources

Revenons aux racines de l’informatique pour y trouver un très bon exemple.
Les agilistes citent volontiers Fred Brooks et son Mythical Man-Month publié en … 1975.
Personnellement, je préfère une histoire encore plus ancienne : celle de Charles Babbage au … 19e siècle.

A l’époque du calcul manuel

Au 19e siècle, la Grande-Bretagne prospère grâce au commerce maritime. Seulement, il arrive que les bateaux se perdent et rencontrent des côtes hostiles entraînant la perte des cargaisons et des équipages. Le GPS n’était pas encore disponible et les marins calculaient des droites de hauteur pour évaluer leurs positions.

Ils utilisaient pour cela des tables pré-calculées en fonction de la période de l’année.

Or ces livres étaient truffés d’erreurs :

• des erreurs de calculs par les armées de calculateurs qui y passaient leurs journées
• des erreurs de recopie sur la fiche « au propre » après le calcul
• des erreurs de recopie lors de l’impression
• des erreurs de calcul sur place

Si on ne peut pas faire grand chose pour le dernier point, Charles Babbage s’est mis en tête d’éliminer les 3 premiers points. Il a donc conçu des machines à calculer. Et pour aller jusqu’au bout, il a même adjoint une presse pour imprimer directement à la sortie du calcul.

La Différence 2 de Charles Babbage

Pour peu que la machine calcule bien, il avait résolu les 3 premières sources d’erreur en automatisant les calculs et leur impression.

En déployant ces machines près des capitaineries, il aurait même pu distribuer ces livres de tables dès le retour au port des bateaux.

Compléments sur Babbage

Pour la petite histoire, Charles Babbage n’a jamais réussi à construire complètement ces machines à calculer (appelées différence n°1 et différence n°2).

Par contre, il a travaillé longuement sur une autre machine qui n’a pas vu le jour non plus : la machine analytique. Elle était dotée :

• d’un dispositif d’entrée avec deux lecteurs de cartes perforées (programmes et données)
• un organe de commande gérant le transfert des nombres et leur mise en ordre pour le traitement ;
• un magasin permettant de stocker les résultats intermédiaires ou finaux ;
• un moulin chargé d’exécuter les opérations sur les nombres ;
• trois types d’imprimantes.

Ça vous rappelle quelque chose : une Unité Arithmétique et Logique, la séparation du programme et des données en entrée, des données imprimées en sortie. Eh oui, il avait inventé le premier ordinateur … mécanique. Il était assisté dans ses travaux par Ada Lovelace, fille de Lord Byron. Elle est depuis considérée comme la première programmeuse de l’histoire. En son honneur, le langage Ada porte son nom. On peut voir notamment son portrait sur les hologrammes d’authentification des produits Microsoft.

Comment le transposer au 21e siècle ?

Aujourd’hui, sur votre téléphone ou tablette, les applications peuvent se mettre à jour dès qu’elles sont publiées.

La plupart d’entre nous ne vérifie pas ces mises à jour. Elles apportent soit de nouvelles fonctionnalités soit des corrections de bugs. En général, nous avons donc tout intérêt à les prendre.

Un testeur dans l’âme ira peut-être jusqu’à vérifier chaque application avant de l’accepter. Mais quel travail !
En fait, nous assumons tout simplement que, si une application est mise à disposition, c’est qu’elle a été vérifiée !

Dans un monde parfait

Dans un monde parfait, le logiciel est reconstruit automatiquement à chaque changement (continuous build). La construction est complète. Elle va jusqu’à préparer l’environnement de déploiement (continuous delivery) : paquets d’installation incluant les mises à jour à faire lors de l’installation. Il est ensuite testé avec toute une batterie de tests pertinents qui qualifie son possible déploiement (continuous testing). Les plus avancés vont même jusqu’à déployer automatiquement (continuous deployment).

Bien sûr, à chaque étape, toute erreur arrête la chaine.

Dans la réalité

Dans la réalité, le travail d’automatisation est coûteux et demande beaucoup de soin. De multiples raisons sont invoquées ou non pour ne pas faire ce travail :

• le coût de ce travail, surtout pour les rares fois ou l’on en a besoin
• la paresse
• la volonté (consciente ou non) de conserver la connaissance
• etc …

Et pourtant, on ne sait jamais à l’avance combien de fois on va utiliser la procédure. On risque toujours un moment d’inattention, une faute de frappe, une perte de mémoire, l’absence du développeur sénior (build guru) qui sait faire, …

Une bonne règle d’automatisation

Dès qu’une opération est répétée plusieurs fois, il faut se poser la question de l’automatiser. La seconde répétition est un message d’alerte. La troisième répétition devrait être le déclencheur du travail d’automatisation.

Elle se résume par la formule : « Avoid the Build guru!«