Les sept erreurs du développeur logiciel moderne

Un logiciel fonctionnel devient une preuve de plus en plus faible que les personnes qui en sont responsables comprennent son fonctionnement. L’IA peut générer des schémas, des règles de sécurité, de l’infrastructure, des documents d’architecture, des tests et des déploiements. Ces résultats peuvent fonctionner et passer les contrôles alors que le développeur ne conserve qu’un modèle mental partiel de ce que l’IA a produit.

Cette distinction est importante, car les pratiques d’ingénierie fournissent des preuves visibles de la qualité des logiciels et des processus. Un pipeline de continuous integration et continuous delivery (CI/CD) propre, qui automatise l’intégration et la mise en production des logiciels, montre que des étapes de build et de déploiement définies peuvent s’exécuter avec succès. Une infrastructure reproductible, des tests étendus et un document de conception cohérent apportent d’autres éléments de preuve. Avec le développement assisté par l’IA, ces artefacts peuvent en révéler moins sur la compréhension humaine qui les sous-tend.

Un logiciel fonctionnel n’établit pas la compréhension humaine

Prenons un déploiement assisté par l’IA. Un développeur demande à une IA de générer l’ossature de l’application et de connecter son back end. Le modèle génère un schéma de base de données qui fait l’objet d’une revue rapide, des règles de sécurité que le développeur ne comprend pas totalement, ainsi que de l’infrastructure-as-code, c’est-à-dire des définitions lisibles par machine des ressources cloud. Le système fonctionne.

Ce résultat met en lumière le problème central. L’IA peut aider à produire des artefacts techniques sophistiqués alors que la personne qui dirige le travail ne comprend qu’une partie du raisonnement qu’ils incarnent.

Les dirigeants sont donc confrontés à deux questions distinctes. Le système fonctionne-t-il dans les conditions testées ? L’équipe comprend-elle pourquoi il fonctionne suffisamment bien pour en assumer la responsabilité ? Les artefacts d’ingénierie peuvent répondre à la première. La seconde exige des preuves de la maîtrise humaine du système.

Les artefacts d’ingénierie peuvent apporter moins de preuves sur leurs créateurs

Le test-driven development (TDD), dans lequel les développeurs écrivent des tests autour du comportement attendu dans le cadre de l’implémentation, produit des tests utiles. Le CI/CD rend répétables des étapes d’intégration et de déploiement définies. Les documents d’architecture consignent les décisions techniques, tandis que l’infrastructure-as-code rend les définitions d’environnement reproductibles.

Ces artefacts peuvent aussi révéler quelque chose sur la manière dont ils ont été produits. Écrire un test exige d’exprimer un comportement attendu. L’infrastructure-as-code encode la manière dont un environnement doit être assemblé, et un document d’architecture consigne des choix techniques.

L’IA affaiblit cette inférence. Un test généré peut détecter une régression, et une définition de déploiement générée peut être reproductible. Mais l’existence de l’un ou l’autre de ces artefacts n’établit pas dans quelle mesure leur relecteur humain les a compris.

L’IA peut préserver l’artefact tout en modifiant sa production

Le débogage montre comment la pratique peut évoluer. Un développeur peut coller une « trace de pile de 200 lignes » entière dans un modèle et demander une correction. Un environnement de développement intégré (IDE) agentique, c’est-à-dire un outil de codage capable d’exécuter des actions en plusieurs étapes, peut identifier une erreur, proposer une solution et l’appliquer après approbation. Il peut aussi fonctionner avec la confirmation automatique activée.

Lorsqu’une réponse échoue, le développeur peut réinjecter l’échec dans le prompt, interdire une bibliothèque, fournir les notes de version d’une interface de programmation d’application (API) actuelle et réduire l’espace des solutions possibles jusqu’à ce que l’erreur disparaisse.

Ce travail exige toujours du jugement. Le développeur doit reconnaître l’échec, choisir des contraintes et évaluer les résultats ultérieurs. Mais cette activité peut différer de la construction d’une explication causale de l’échec. Le développeur peut plutôt orienter le modèle vers un résultat qui passe le contrôle immédiat.

Le même schéma peut s’appliquer ailleurs. L’IA peut traduire une logique JavaScript existante en Rust ou développer une idée architecturale incomplète en un document de conception abouti avec des spécifications techniques et des diagrammes de séquence. Le résultat peut ressembler à un artefact produit par un ingénieur qui a personnellement parcouru une plus grande partie du raisonnement intermédiaire.

Le cas le plus difficile : quand l’IA écrit à la fois le code et la preuve

Les tests rendent cette distinction particulièrement claire, car ils fournissent des preuves sur le code.

L’affirmation selon laquelle l’IA peut fournir « 95 % de couverture de test presque sans effort » doit être vérifiée. La couverture de test mesure la part du code exercée par une suite de tests selon une métrique de couverture donnée. Un pourcentage élevé peut montrer une large exécution par les tests, mais il n’établit pas que les tests contiennent un raisonnement indépendant sur les exigences.

Un développeur peut demander au même modèle de générer la logique applicative et ses tests unitaires, tests d’intégration, smoke tests, mocks, assertions et cas limites. Un mock est une version simulée d’un composant externe utilisée pendant les tests.

Supposons qu’un modèle génère une implémentation à partir d’une hypothèse erronée sur un cas limite. S’il reprend cette hypothèse dans le test correspondant, l’implémentation et l’assertion peuvent être cohérentes, et le test peut réussir. Un mock généré peut créer le même problème lorsque l’implémentation et le mock reflètent tous deux une même compréhension erronée d’une dépendance externe.

Il s’agit d’un angle mort corrélé : des artefacts distincts partagent une erreur parce qu’ils dérivent de la même hypothèse sous-jacente. Un examen indépendant peut remettre en cause cette hypothèse commune. Des tests générés à partir du même modèle et du même contexte que l’implémentation peuvent offrir un examen moins indépendant lorsque les deux héritent de la même erreur.

L’enjeu de management est précis. La couverture mesure la relation entre les tests et le code. Les responsables de l’ingénierie doivent évaluer séparément si quelqu’un a remis en cause les hypothèses qui sous-tendent les deux.

Le développement assisté par l’IA peut déplacer les compétences requises

Produire un logiciel fonctionnel avec l’IA peut exiger du jugement. Dans l’exemple du débogage, le développeur reconnaît les régressions, ajuste les contraintes, rejette les mauvaises approches et fournit les informations manquantes. Une fenêtre de contexte, c’est-à-dire la quantité d’informations qu’un modèle peut prendre en compte à un moment donné, peut limiter l’interaction. Les modèles peuvent aussi utiliser des API obsolètes ou ne pas suivre les instructions.

La persévérance et la capacité à contraindre un modèle peuvent compter dans l’ingénierie assistée par l’IA. Ces compétences démontrent une maîtrise du processus de production. À elles seules, elles ne démontrent pas la connaissance de chaque hypothèse déterminante dans le système résultant.

Pour les CTO, cela distingue deux mesures qui peuvent autrement être confondues : la capacité à mener à bien un travail d’ingénierie avec l’IA et la capacité à expliquer le système qui en résulte et à réagir lorsqu’il se comporte en dehors du chemin déjà exploré avec le modèle.

La responsabilité exige des preuves directes

Un build propre établit que les étapes de build définies ont réussi. Un déploiement montre que les étapes de déploiement définies ont réussi, tandis que les tests montrent que les assertions spécifiées ont réussi dans les conditions testées. Un document d’architecture consigne une description du système.

Les organisations ont aussi besoin de preuves que les ingénieurs responsables peuvent expliquer les hypothèses déterminantes, enquêter sur des comportements surprenants et prendre des décisions lorsque les correctifs générés échouent. Elles peuvent demander aux ingénieurs d’expliquer directement les choix de conception critiques et les modes de défaillance, puis confronter ces explications au système en fonctionnement et à ses exigences. Cela mesure la maîtrise humaine du système lui-même au lieu de l’inférer uniquement à partir des artefacts qui entourent le logiciel.

Principaux enseignements pour les dirigeants

• Un logiciel fonctionnel ne prouve pas la compréhension humaine : l’IA peut produire des systèmes opérationnels alors que les développeurs ne conservent qu’un modèle mental partiel. Les dirigeants doivent évaluer si les ingénieurs responsables peuvent expliquer les décisions de conception déterminantes, les hypothèses et les modes de défaillance.
• Les artefacts d’ingénierie sont des preuves plus faibles de l’expertise : les tests, les pipelines CI/CD, les documents d’architecture et l’infrastructure-as-code restent précieux, mais l’IA peut les générer sans compréhension humaine équivalente. Évaluez séparément la qualité de l’artefact et la maîtrise qu’en a l’ingénieur.
• L’IA change la manière dont le travail d’ingénierie est réalisé : les développeurs peuvent orienter les modèles vers des correctifs efficaces sans construire pleinement le raisonnement causal qui les sous-tend. Les dirigeants doivent distinguer un usage efficace de l’IA de la capacité à diagnostiquer de manière autonome des défaillances inconnues.
• Le code et les tests générés par l’IA peuvent partager des angles morts : lorsque le même modèle génère à la fois l’implémentation et la validation, des hypothèses erronées peuvent apparaître dans les deux tout en produisant des tests réussis. Exigez un examen indépendant des exigences critiques, des cas limites et des dépendances externes.
• Le développement assisté par l’IA déplace les compétences qui comptent : le prompting, la définition de contraintes, la supervision du modèle et la reconnaissance des défaillances sont des compétences d’ingénierie de plus en plus utiles, mais elles ne remplacent pas la connaissance du système. Mesurez à la fois la productivité rendue possible par l’IA et la maîtrise technique.
• La responsabilité exige des preuves directes : des builds, déploiements et tests réussis établissent que les contrôles définis ont été passés, et non que les ingénieurs comprennent pourquoi le système fonctionne. Demandez aux ingénieurs responsables d’expliquer les hypothèses critiques et les modes de défaillance, puis validez ces explications par rapport aux exigences et au comportement du système.