Diagnostic automatisation : ce que je regarde avant de parler outil
Une règle de diagnostic pour revenir à la boucle de feedback réelle avant de choisir un outil, lancer une automatisation ou accepter une piste technique trop lourde.
Quand un client me dit “il faut automatiser” ou “il faut mettre tel outil”, je ne pars pas du principe qu’il a tort.
Mais je ne pars pas non plus du principe qu’il a raison.
Dans un cas récent, le sujet arrivait par le développement et l’infrastructure. L’équipe avait du mal à livrer vite. La première piste formulée était assez claire : utiliser Docker depuis le poste du développeur, dans la CI, puis jusqu’à la production.
Sur le papier, la direction n’était pas absurde. Elle pouvait même avoir du sens à moyen terme.
Mais ce n’était pas encore un diagnostic. C’était une solution proposée avant d’avoir regardé tout ce qui ralentissait vraiment le flux.
La collecte a fait apparaître des signaux
Je n’ai pas eu un moment où tout a basculé d’un coup.
Pendant la collecte, les développeurs parlaient de leurs frictions quotidiennes, la QA décrivait une charge qui débordait, et certaines habitudes d’infrastructure apparaissaient comme normales alors qu’elles coûtaient du temps ou de l’argent.
C’est au moment de construire la roadmap que les pièces se sont alignées.
La piste Docker restait intéressante, mais trop lourde pour traiter les urgences. Elle demandait beaucoup de changements, beaucoup de coordination, et une trajectoire difficile à faire passer en une seule phase courte.
Le premier gain était ailleurs.
Les signaux qui comptaient vraiment
Le premier signal venait des développeurs.
Changer de branche pouvait prendre environ quinze minutes, à cause d’une synchronisation entre le poste du développeur et l’instance de développement en SFTP. Ce n’est pas seulement quinze minutes perdues. C’est aussi une friction qui décourage les tests sur plusieurs versions, rend les revues de code moins confortables, et laisse passer plus facilement des erreurs.
Le deuxième signal venait de la QA.
Elle était débordée. Elle portait les tests de non-régression, beaucoup de tests utilisateurs, et n’avait plus assez de place pour faire correctement les tests fonctionnels qui valident qu’une fonctionnalité vendue à un client marche vraiment.
Le troisième signal venait de la CI.
GitLab pouvait signaler des erreurs au moment du push, mais cela ne changeait pas vraiment le flux : on poussait quand même, et la CI servait surtout à déplacer le code vers la QA, pas à sécuriser la livraison.
À ce stade, parler seulement de Docker aurait été trop court.
Avant l’outil, regarder la boucle de feedback
Une automatisation ou un outil peut être utile. Mais si la boucle de feedback est lente, floue ou non bloquante, l’outil arrive souvent trop tôt.
Dans ce cas, les sujets court terme étaient plus proches du quotidien :
- simplifier les environnements de développement
- réduire le coût des changements de branche
- ajouter des tests côté dev
- rendre la CI plus utile avant que le code arrive en QA
- clarifier ce qui doit bloquer, alerter ou simplement informer
- traiter les coûts d’infrastructure qui tournaient sans usage réel
Ce sont des sujets moins spectaculaires qu’une trajectoire Docker complète. Mais ils répondaient mieux au problème immédiat : livrer plus vite, avec moins de frictions et moins d’erreurs.
Les cinq questions que je garde
Avant de parler outil, je reviens toujours à quelques questions simples.
Est-ce que le problème revient souvent ?
Où sont les exceptions ?
Quel est le coût réel : temps, erreurs, relances, attente, dépendance à une personne ?
Que se passe-t-il si une automatisation se trompe ou si un signal est ignoré ?
Qui devra maintenir la solution quand elle ne marchera pas comme prévu ?
Si les réponses sont floues, je ne parle pas encore de solution. Je commence par rendre le sujet assez clair pour décider.
Parfois, la bonne suite est bien une automatisation. Parfois, c’est une simplification. Parfois, c’est une roadmap en deux temps : traiter d’abord ce qui bloque aujourd’hui, puis garder une piste technique plus ambitieuse pour plus tard.
Dans ce cas, Docker n’a pas disparu de la réflexion. Il a simplement repris sa place : une direction possible à moyen terme, pas le premier levier pour éteindre le feu.