Chaque vendredi, une salariée prépare le montant des affaires gagnées pour la réunion commerciale. Elle exporte les données, retire les doublons, calcule le total et met en forme le fichier. Cela lui prend une heure.
Une collègue propose un essai d’automatisation. Le responsable lui demande de préparer une note. Une autre équipe doit donner son accord, mais aucune date de réponse n’est fixée et personne ne sait qui pourra autoriser l’essai en son absence.
Ce cas est construit pour l’article. L’heure hebdomadaire et les montants qui suivent sont des données d’exemple. Le travail à examiner est précis : produire le même rapport sans recopier chaque semaine les mêmes informations.
Quatre semaines plus tard, six heures ont été consacrées au sujet
Dans ce scénario, quatre semaines passent sans décision. Le fichier a été préparé quatre fois, pour quatre heures de travail. La collègue a aussi consacré deux heures à sa note et aux échanges de validation.
L’entreprise a donc dépensé six heures et conserve exactement le même traitement manuel. Cela ne prouve pas que l’automatisation aurait réussi en deux heures. Cela établit le coût de l’absence de décision pendant cette période.
La note décrit un essai qui ne modifierait aucune donnée commerciale et ne remplacerait pas encore le rapport. Une réponse pourrait demander une vérification supplémentaire, fixer une date ou refuser l’essai pour une raison précise. Dans le cas retenu, aucune de ces décisions n’arrive.
Le vendredi suivant, la tâche manuelle aura toujours une échéance connue. La proposition d’amélioration n’en aura toujours pas. Continuer à préparer le tableau suffit à remplir l’obligation de la semaine. Relancer l’essai ajoute du travail sans donner de date à son résultat.
Le total automatique serait faux de 1 200 euros
La personne qui prépare le rapport objecte que l’export contient des doublons. Voici les trois lignes du jeu d’exemple. Le montant correspond au total de chaque affaire, pas à une part attribuée au commercial.
| Affaire | Commercial associé | Montant total de l’affaire |
|---|---|---|
| A42 | Ancien responsable | 1 200 € |
| A42 | Nouveau responsable | 1 200 € |
| B17 | Responsable actuel | 800 € |
L’affaire A42 apparaît deux fois à la suite d’un changement de responsable. Additionner les lignes donne 3 200 €. Compter une fois chaque affaire donne 2 000 €. La préparation manuelle retire donc ici 1 200 € qui seraient comptés à tort.
Remplacer la copie par une somme automatique reproduirait l’erreur chaque vendredi. L’objection contient la règle qui manquait dans la proposition : le rapport doit compter les affaires, pas les lignes de l’export.
Un essai qui peut être accepté ou refusé sur un résultat
Le périmètre de l’essai peut maintenant être écrit sans demander une confiance générale dans l’automatisation. Il utilise une copie de l’export, produit un second fichier et laisse le rapport habituel inchangé.
Sur le jeu ci-dessus, le résultat attendu est 2 000 €. L’affaire A42 doit apparaître une seule fois. Si deux lignes portant le même identifiant contiennent des montants différents, l’outil doit signaler le conflit au lieu d’en choisir un silencieusement.
La personne qui prépare le rapport compare ensuite les deux fichiers sur des exports réels autorisés pour l’essai. Tout écart doit être expliqué avant le remplacement du fichier habituel. Une décision est alors possible sur des résultats consultables.
La collègue peut choisir comment produire ce second fichier. Elle ne peut pas modifier la définition d’une affaire gagnée, supprimer une ligne en conflit ou transmettre l’export à un service non autorisé. L’autonomie a ici des limites que l’on peut vérifier dans le travail.
Au Drynuary, certaines décisions étaient déjà prises
Chez Gridky, pendant le Drynuary, nous n’avions pas à faire approuver chaque fois la priorité de la stabilisation. Le CTO et le CEO avaient convenu de suspendre les nouvelles fonctionnalités. Cette décision s’appliquait à toute l’équipe, y compris aux demandes du client prioritaire.
Les développeurs choisissaient leurs sujets en tenant compte de la criticité et des exceptions récurrentes. Le code touché devait être testé et passait en revue avant intégration. Le choix de la correction restait à l’équipe, le niveau de vérification n’était pas laissé à la préférence de chacun.
C’est la répartition des décisions que je peux décrire dans ce cas réel : l’arbitrage produit avait eu lieu avant le chantier, les choix de réalisation se faisaient dans l’équipe, et la revue contrôlait le résultat. Nous avions une équipe senior et convaincue du besoin.
Une autorisation d’essayer ne vaut pas autorisation de remplacer
Dans l’exemple du rapport, le premier feu vert porte sur un fichier parallèle. Le remplacement du rapport arrive plus tard, après comparaison des résultats. Confondre ces deux décisions oblige à justifier le fonctionnement définitif avant même d’avoir le droit de le vérifier.
Les doublons donnent une bonne raison de ne pas remplacer immédiatement le travail manuel. Ils donnent aussi un cas précis sur lequel tester la proposition. L’objection devient alors une vérification attendue, avec un résultat de 2 000 €, plutôt qu’un motif d’attente sans date.
Le prochain vendredi permet de constater ce qui a changé : un essai a été autorisé et produit un fichier comparable, ou la même salariée refait seule le même travail. Une demande d’initiative formulée en réunion ne modifie aucun de ces deux résultats.
Le délai qui suit un travail déjà terminé est traité dans Une correction terminée mardi, livrée la semaine suivante. Ces deux situations se retrouvent dans les cinq visages de la dette technique.