Je l’ai déjà dit et je le répète, mais j’aime regarder les masses bouger. Et de là, en tirer des modèles. De temps en temps, c’est débile (même souvent), mais de temps en temps, j’ai l’impression de ne pas tomber si loin de la vérité (pour ce que ce mot veut dire).
Un peu d’histoire. Quand je travaillais dans une énorme entreprise de transport, des processus informatiques, il y en avait à la pelle. Une partie de mon job était tout simplement d’analyser ces processus et de les documenter. Pourquoi ? Parce qu’ils étaient vieux, et que le gars qui avait codé cela dans son garage était soit sur le point de partir à la retraite, soit à la retraite, soit en conversation avec Dieu.
Avec mon bâton de pèlerin, je passais mon temps à lire des lignes de codes abscons afin d’en sortir une piètre forme reconnaissable. Et de fil en aiguille, un pattern en est sorti. Celui de la rustine.
Au départ, il y a un gaillard à qui on demande de créer un script à qui prend en entrée des données A afin d’en faire des données B (sauvegardé dans un fichier fB par exemple). Il teste, il est content, il met en prd et ainsi le code est utilisé tous les jours. (donc a (A) => B)
Puis, quelque temps après, pour des raisons aussi diverses que varier, les données B ne conviennent plus. Soit parce qu’elles n’ont plus d’utilité, soit parce qu’on s’est rendu compte qu’une erreur n’avait pas été remarquée, soit plein d’autres raisons.
Et c’est là le truc. Au lieu de corriger le script a, au lieu d’augmenter les données B avec ce qui est nécessaire, il va être mis en place un script « b » qui va lire les données B pour en sortir des données C. C contenant non seulement les informations A, mais aussi les informations B erronées, + les informations C (qui ne sont jamais que les informations B corrigées.).
Puis plus tard… rebelote, on recommence. Les informations C sont soit inexactes soit incomplètes. On créé un script « c » qui prend en entrée les données C (sous forme de fichier ou autre) et on en sort une donnée D, etc., etc., etc. vous avez compris.
La question est pourquoi ? Pourquoi ne pas tout refaire au propre, pourquoi ne pas réparer ce qui est cassé plutôt que de créer un script ?
Pour avoir été dans pas mal de meetings, il y a une phrase qui revient souvent. Une phrase illogique, mais rassurante : « On ne touche pas ce qui marche ».
Comme il y a pleins d’historiques, c.-à-d. pleins de décisions sans raison qui ont été prises, comme personne ne sait comment fonctionne exactement, comme personne ne sait exactement qui utilise quoi, on ne touche pas.
C’est ainsi que dans des entreprises de plusieurs dizaines d’années, les processus de rustines sont légion. Toute personne qui travaille dans une entreprise avec des excels, des bases de données, des fichiers connaissent cela.
Mais là où c’est drôle, c’est que j’ai l’impression que ce schéma s’applique à beaucoup de choses.
Prenez les BS jobs. Je suis en train de lire un livre de… ou ils parlent des gens qui sont engagés à des postes ou ils ne servent à rien. Pourquoi ? Simplement parce qu’on ne touche pas ce qui marche déjà.
Remplacer dans le processus de rustine les scripts par des gens, vous aurez la même chose.
Une personne reçoit des données A et les transforment en B etc.
Alors vous objectivez que les gens ne sont pas des machines, qu’ils parlent entre eux, etc., mais vous oubliez la puissance du mail. Combien de contacts au travail ne vous sont connus que par le mail ? Combien de personnes n’ont aucun visage ! Il suffit qu’un seul maillon soit une machine et que tous les autres ne veuillent chercher à comprendre pour ne se rendre compte de rien. Si ça marche, on ne touche pas.
1re règle, un processus de rustine est fait pour durer.
Alors vous allez me dire. Oui, mais moi, on a fait une refonte de tout le système, etc.
Et là se pose la question. Car oui, cet historique, ce processus abscons, de temps en temps on y touche, mais quand.
Je vais vous le dire… quand il ne marche plus. Quand il n’y a plus de choix. Par exemple, imaginer un processus de rustine qui mène à la conduite des trains. (les horaires, etc., etc.). À quel moment le management (qui se fout du technique) va revoir toute la chaine ? Quand les trains ne rouleront plus. Quand, dans la presse, la réputation sera atteinte.
Là, il y aura une crise, et il faudra y répondre de manière forte. Et par forte, j’entends creuser.
2e règle : Un processus de rustine n’est remis en cause que lorsqu’il y a un incident assez grave pour qu’il en devienne visible.
Là où c’est drôle, c’est qu’améliorer les erreurs plutôt que de les réparer, j’ai l’impression de voir cela un peu partout. Par exemple : Le changement climatique, la pollution des bagnoles, etc.
Prenez la voiture. Au début, vous avez la création d’une voiture. Puis on s’est rendu compte qu’elle faisait trop de bruit. Au lieu de ralentir, on a mis un pot d’échappement, puis on s’est rendu compte qu’elle polluait, au lieu de ralentir, on a mis un pot catalyseur, puis on s’est rendu compte qu’elle tuait, alors on a rajouté des ceintures, puis, etc. puis, etc.
Et c’est seulement depuis quelques années, car il y a une catastrophe qu’on est en train de détricoter tout le processus pour aller vers de l’intelligence artificielle complexe avec batteries.
On aurait pu y aller plutôt. Chaque feu rouge pourrait avoir une intelligence et communiquer avec la bagnole, chaque panneau depuis des années pourrait aider la voiture à prendre des décisions sur la vitesse a prendre (via le wifi, la radio, etc.)… mais non les gens ont le droit de rouler comme des tarés, on les laisse faire. Processus de rustine.
D’autres exemples me viennent en tête, mais je pense que vous avez compris. Et je suis sûr que maintenant vous ne verrez que cela.
