2 Tout le monde parle du développement assisté par l’IA : benchmarks, gains de productivité, « ingénieurs 10x », code écrit en quelques secondes. On parle moins de ce qui se passe une fois que l’IA a écrit le code. Chez Scality, nous avons appris que le vrai progrès ne se joue pas dans le prompt. Il se joue dans le diff, c’est-à-dire l’écart entre ce que génère l’IA et ce que l’ingénieur décide finalement de livrer. L’IA ne s’améliore pas d’elle-même. Elle s’améliore lorsque quelqu’un étudie ses résultats, les remet en question et réinjecte les enseignements dans le système. Regarder le travail réel En tant que VP Engineering, je supervise huit équipes d’ingénierie qui travaillent sur des systèmes de stockage distribué dans plusieurs langages et technologies, dont C, Go, Python, JavaScript et React. Notre travail s’étend de la gestion matérielle de bas niveau à l’interface d’administration que nos clients utilisent au quotidien. Mon rôle consiste notamment à maintenir des standards de performance et à accompagner le développement de nos managers d’ingénierie. Au cours de l’année écoulée, à mesure que les outils d’IA s’intégraient à notre façon de travailler, je me suis appuyé sur un principe issu de l’industrie manufacturière : le gemba (en anglais). Plusieurs fois par semaine, je m’assois avec un ingénieur et son manager. Nous ne passons pas en revue des slides, nous ne débattons pas des priorités de la feuille de route : nous examinons le travail réel. Les vrais prompts Le code généré La version finale livrée Et surtout, le diff entre ce que l’IA a produit et ce que l’ingénieur décide finalement de livrer. Si vous voulez comprendre comment l’IA transforme la pratique de l’ingénierie, c’est là que se trouve le signal. Le gemba dans le développement IA : le véritable atelier, c’est la base de code Dans l’industrie, le gemba consiste à se rendre à l’atelier, là où le travail se fait réellement. Pour les équipes d’ingénierie, l’atelier, c’est la base de code. Dans un workflow assisté par l’IA, il englobe aussi les prompts, les fichiers de configuration partagés et les résultats produits par ces systèmes. Dans cet environnement, le rôle du management ne consiste pas à valider des outils, mais à rester suffisamment proche du travail pour comprendre comment ces outils se comportent en pratique. Lorsque vous vous asseyez avec les ingénieurs pour revoir les diffs ensemble, vous voyez le jugement à l’œuvre : là où quelque chose a été simplifié là où un pan de logique a complètement disparu là où une abstraction a été réécrite pour mieux s’intégrer au système là où le code généré a été accepté tel quel Les indicateurs ne montrent pas ce niveau de détail. On ne le voit qu’en regardant directement le travail. Ce que les diffs révèlent du code généré par l’IA Les outils de développement assisté par l’IA sont indéniablement utiles. Ils accélèrent les itérations et suppriment une bonne partie du travail mécanique. Mais dès que l’on passe du temps à examiner les diffs, certains schémas sautent aux yeux. L’IA a souvent tendance à sur-concevoir. Elle introduit des abstractions inutiles pour le système concerné, ou répète une logique sur plusieurs couches là où un ingénieur la regrouperait. Parfois, le code généré fonctionne techniquement et passe même les tests, sans pour autant être prêt pour la production. Rien de tout cela n’est surprenant. Le modèle optimise pour des solutions générales, l’ingénieur pour le contexte. C’est dans la tension entre ces deux perspectives que réside une grande partie du savoir d’ingénierie. Pourquoi le diff compte davantage que le prompt Le premier résultat n’est pas l’artefact. L’artefact qui compte, c’est l’écart entre la sortie de l’IA et la version finale relue par l’ingénieur. Cet écart contient le jugement d’architecture, les arbitrages de performance, les conventions apprises en production et la discipline qui garantit la fiabilité des systèmes. Si vous n’étudiez pas cet écart, vous passez à côté du signal. Et si le raisonnement qui sous-tend ces modifications n’est jamais capturé, l’organisation ne progresse pas vraiment. Le code s’améliore, mais pas le système qui le génère. Les ingénieurs restent maîtres de la boucle de rétroaction Ce n’est pas l’IA qui maîtrise la boucle de rétroaction, ce sont les ingénieurs. L’IA ne peut ni s’évaluer ni se corriger elle-même : elle n’a ni jugement ni responsabilité. Lorsque l’IA génère du code qui doit être modifié, c’est l’ingénieur qui se soucie des conséquences. Mais la vraie rétroaction ne se limite pas à corriger le code. Elle consiste à se demander pourquoi l’IA l’a généré ainsi, puis à mettre à jour le système qui façonne ses résultats : affiner les frameworks de prompts partagés, mettre à jour les fichiers de configuration, renforcer les recommandations d’architecture ou formaliser les standards qui reviennent régulièrement dans les diffs. Autrement dit, les humains ne se contentent pas de corriger le code : ils améliorent le système qui le génère. Au fil du temps, lorsque les schémas récurrents des diffs sont réinjectés dans les prompts, les configurations et les standards d’ingénierie, les outils deviennent plus utiles, tout en restant des outils au sein d’un système piloté par des humains. L’adoption de l’IA est une pratique d’ingénierie, pas un choix d’outil De nombreuses organisations abordent l’adoption de l’IA comme un choix d’outil : quel modèle ? quel fournisseur ? quelle licence ? Ces questions comptent, mais la maturité ne vient pas des achats. Elle vient de l’implication du management dans les workflows réels : observer directement les frictions, transformer les corrections récurrentes en standards et améliorer en continu le système d’ingénierie. L’IA progresse lorsque votre système d’ingénierie progresse, et cela exige de la discipline. La discipline derrière la productivité L’IA est puissante. Elle accélère les itérations et permet aux ingénieurs d’essayer des choses qui auraient pris bien plus de temps auparavant, mais elle n’améliore pas automatiquement la manière dont une organisation construit ses logiciels. L’amélioration se fait toujours de la même façon : par la relecture, par les diffs, par l’accumulation de petites décisions d’ingénierie qui façonnent les systèmes de production au fil du temps. C’est cet état d’esprit qui guide notre adoption de l’IA chez Scality, de la même manière que nous construisons des logiciels résilients et performants : par l’observation, l’itération et une pratique d’ingénierie rigoureuse, loin de l’effet de mode.
