Votre direction veut aller plus vite dans le code. Ce n'est pas toujours la bonne décision.

Le réflexe : accélérer le code quand la pression monte

Un projet SI prend du retard, ou n'avance simplement pas assez vite au goût de la direction. Le réflexe le plus courant est de demander au prestataire d'accélérer le développement : plus de ressources, moins de réunions, moins de questions, plus de lignes de code livrées chaque semaine. La vitesse de code devient le seul indicateur d'avancement visible, parce que c'est le plus facile à demander et à mesurer depuis un comité de direction.

Le problème n'est pas la volonté d'avancer vite, elle est saine. Le problème est de confondre la vitesse de décision, qui peut et doit être rapide, avec la vitesse d'écriture du code, qui encode des règles métier bien réelles. Un code écrit avant que ces règles soient comprises et validées ne fait pas gagner de temps : il déplace le travail de compréhension vers la production, au moment le plus coûteux pour le faire.

Sur un projet de back-office commercial pour une ETI du secteur de l'énergie, la direction avait des contraintes fortes pour avancer vite dans le code. La logique était compréhensible : des contrats en tension, une équipe commerciale qui attendait un outil depuis longtemps. Une première tentative avec des freelances avait d'ailleurs déjà cédé à cette pression, avec le résultat qu'on retrouve souvent dans ce genre de situation, du code livré, mais aucune structure derrière. Pour comprendre ce que produit ce schéma : ce que les freelances livrent et ce qui manque systématiquement.

Ce que la vitesse cache réellement

Un développement rapide sur un périmètre mal cadré ne fait pas disparaître le travail de compréhension, il le reporte. Chaque règle métier non formalisée en amont ressort en production sous forme de bug, d'exception non gérée, ou de comportement inattendu que les utilisateurs découvrent en travaillant. Ce report a un coût supérieur au temps qu'il aurait fallu pour le traiter en amont, parce qu'il s'accompagne d'une correction sous pression, sur un système déjà utilisé.

C'est exactement ce qui s'est joué sur ce projet. La direction poussait pour avancer vite dans le code, avec de bonnes raisons commerciales. Le rôle qu'on a tenu a consisté à ralentir volontairement cette vitesse, le temps de cartographier les scénarios non nominaux du métier énergie, soutirage, injection, règles Enedis, TURPE, qui n'apparaissent jamais dans un scénario nominal mais qui gouvernent une bonne partie des cas réels.

« Aller trop vite dans le code allait aussi avoir ses limites. »

Cette tension entre vitesse voulue et vitesse tenable n'est pas propre à un secteur. Elle apparaît sur tout projet où l'IA générative accélère l'écriture du code sans accélérer la compréhension du métier qu'il encode. Sur ce sujet précis : pourquoi l'accélération du code par l'IA se paie souvent après coup.

Le rôle de garde-fou : dire non à la vitesse, pas au projet

Jouer les freins ne veut pas dire ralentir le projet, ça veut dire séquencer correctement le cadrage et le développement. Un garde-fou ne bloque pas l'avancement, il refuse que le code avance sur un périmètre encore instable. La différence se voit dans le résultat : un projet correctement séquencé accélère franchement une fois le cadrage posé, parce que le développement n'a plus besoin de redécouvrir les règles métier en cours de route.

Concrètement, ce rôle se traduit par trois réflexes. Refuser de démarrer un développement tant que le modèle de données n'a pas absorbé les scénarios non nominaux identifiés en cadrage. Documenter chaque décision de périmètre pour qu'elle reste traçable quand la direction demande pourquoi telle fonctionnalité n'est pas encore livrée. Et accepter la friction du désaccord de court terme, parce qu'un accord de fond sur la méthode compte davantage qu'une adhésion immédiate sur le rythme.

Ce rôle ne se substitue pas à la direction, il la complète. Il permet à la direction de continuer à décider vite sur ce qui relève d'elle (les priorités, le budget, les arbitrages métier) pendant que le rythme du code suit une logique différente, déterminée par ce que le périmètre peut absorber sans redécouverte permanente. Sur la manière dont ce pont se construit entre les deux mondes : comment traduire l'expertise métier en architecture robuste.

Ce que ça change dans la durée

Sur le projet évoqué plus haut, la tension entre vitesse demandée et vitesse tenable a généré des frictions réelles, des désaccords, des allers-retours. Mais l'accord de fond sur le principe d'une colonne vertébrale qui tient dans le temps a été maintenu. Résultat un an plus tard : l'audit annuel du groupe, mené par un cabinet tiers, a qualifié la différence de « jour et nuit » par rapport à l'année précédente, quand le projet reposait encore sur du code livré sans structure.

La vélocité du code n'a jamais été sacrifiée, elle a été replacée après la vélocité de compréhension. Un projet qui accepte de ralentir pendant deux à trois semaines pour cartographier ses règles métier avance ensuite plus vite et plus longtemps qu'un projet qui code en continu sans jamais s'arrêter pour vérifier ce qu'il encode réellement.

Si votre direction pousse aujourd'hui pour accélérer un développement en cours, la première question à poser n'est pas combien de temps ça prendrait d'aller plus vite. C'est quelles règles métier n'ont pas encore été formalisées sur le périmètre concerné, et ce qu'il en coûterait de les découvrir en production plutôt qu'en amont.