The Engineer-in-the-Loop: Best Practices for AI-Assisted App Development

Chaque équipe d'ingénierie en 2026 utilise le développement assisté par l'IA sous une forme ou une autre. Copilot, Cursor, Claude, ChatGPT — ces outils sont intégrés dans nos IDE, nos terminaux, nos workflows de révision de code et nos pipelines de déploiement. Les gains de productivité sont réels : génération de code standard, scaffolding de tests, intégration d'API et documentation se font plus rapidement que jamais.

Mais nous avons un problème. Et ce n'est pas celui dont la plupart des gens parlent.

Le problème n'est pas que l'IA écrit du mauvais code. Les LLM modernes écrivent un code étonnamment compétent pour des tâches bien définies. Le problème est que les équipes perdent la capacité d'évaluer ce que l'IA produit. Nous observons un modèle que nous appelons « fusionner sans comprendre » — où le code généré par l'IA passe les tests, passe la révision (souvent également assistée par l'IA) et est déployé en production sans qu'aucun humain ne comprenne vraiment ce qu'il fait ou pourquoi il a été implémenté de cette façon.

Chez iHux, nous avons passé les deux dernières années à développer un framework ingénieur-dans-la-boucle qui capture la vitesse de l'assistance IA tout en maintenant la compréhension, la responsabilité et l'artisanat qui définissent un grand logiciel. Voici ce que nous avons appris.

Les vrais risques du développement assisté par l'IA non structuré

Avant de prescrire des solutions, soyons honnêtes sur ce qui peut mal tourner. Ce sont des modèles que nous avons observés au sein de notre propre équipe et lors de conversations avec des dizaines d'organisations d'ingénierie :

• Architecture de culte du cargo. L'IA suggère des modèles issus de ses données d'entraînement — souvent des abstractions de niveau entreprise pour des problèmes qui nécessitent des solutions simples. Les équipes se retrouvent avec des modèles de référentiel enveloppant des ORM enveloppant des bases de données pour des applications qui ont trois tables.
• Dette technique invisible. Le code généré par l'IA fonctionne souvent mais n'est pas idiomatique. Il peut utiliser des API dépréciées, ignorer les conventions du framework ou implémenter des solutions qui sont correctes mais non maintenables. Cette dette est plus difficile à détecter car le code fonctionne bien — jusqu'à ce que quelqu'un ait besoin de le modifier.
• Atrophie des compétences. Les jeunes ingénieurs qui s'appuient fortement sur l'IA pour la mise en œuvre ne développent jamais l'intuition approfondie de résolution de problèmes qui vient de la lutte contre des problèmes difficiles. Les ingénieurs seniors qui acceptent automatiquement les suggestions de l'IA cessent de remettre en question les décisions architecturales. Ces deux résultats affaiblissent l'équipe au fil du temps.
• Points aveugles en matière de sécurité. Les modèles d'IA n'ont pas votre modèle de menace dans leur fenêtre de contexte. Ils généreront volontiers du code avec des vulnérabilités d'injection SQL, des paramètres par défaut non sécurisés ou des politiques IAM trop permissives — et cela passera les tests fonctionnels parce que les tests ne vérifient pas les propriétés de sécurité.

Le cadre Engineer-in-the-Loop

Notre cadre n'a pas pour but de restreindre l'utilisation de l'IA — c'est l'organiser de manière à ce que les humains restent les décideurs tandis que l'IA gère l'exécution. Pensez-y comme au même principe derrière les véhicules autonomes : la technologie gère les opérations de routine, mais un humain doit suffisamment bien comprendre le système pour intervenir en cas de besoin.

Principe 1 : Concevoir avant de générer

L'anti-pattern le plus courant est de demander à l'IA de « me construire une fonctionnalité » sans d'abord réfléchir à la conception. Lorsque vous laissez l'IA piloter les décisions architecturales, vous obtenez du code architecturalement incohérent — chaque fichier généré peut être bien structuré en interne mais le système dans son ensemble manque d'une philosophie de conception cohérente.

Notre règle : Chaque tâche commence par un brief de conception rédigé par un humain. Avant que l'IA ne génère un code quelconque, l'ingénieur rédige un brief spécifiant : le problème à résoudre, l'approche prise et pourquoi, les interfaces entre ce code et le reste du système, ainsi que les contraintes (performance, sécurité, compatibilité). Ce brief devient le contexte du prompt et les critères d'examen. L'IA génère la mise en œuvre. L'humain possède la conception.

Principe 2 : Examiner pour la compréhension, pas seulement pour l'exactitude

L'examen traditionnel du code demande : « Cela fonctionne-t-il ? » L'examen du code assisté par l'IA doit en plus se demander : « Comprends-je pourquoi cela fonctionne ? » et « Serais-je à l'aise pour déboguer cela à 2 heures du matin ? » Si la réponse à l'une ou l'autre question est non, le code ne fusionne pas — indépendamment de si les tests réussissent.

Nous avons mis en place une pratique spécifique : l'auteur du code généré par l'IA doit être capable d'expliquer chaque fonction et chaque choix architectural dans la description de la PR sans référencer la conversation avec l'IA. Si vous ne pouvez pas l'expliquer, vous ne le comprenez pas. Si vous ne le comprenez pas, il ne sort pas.

Principe 3 : L'IA pour l'accélération, pas le remplacement

Il y a des tâches où l'IA accélère véritablement les ingénieurs compétents, et des tâches où elle crée une illusion de productivité. Connaître la différence est crucial :

L'IA excelle dans : la génération de code boilerplate, la rédaction de tests (lorsque des spécifications claires sont données), le code d'intégration d'API, la logique de transformation de données, la génération de documentation, la refactorisation de modèles bien définis, et la traduction entre des langages ou des frameworks que vous comprenez déjà conceptuellement.

L'IA a du mal avec : les décisions d'architecture novatrice, les chemins de code critiques pour les performances, la logique sensible en matière de sécurité, le code qui doit s'intégrer à des systèmes internes mal documentés, tout ce qui nécessite une compréhension de votre domaine métier spécifique, et le débogage de problèmes complexes multi-systèmes.

Le cadre ici est simple : utilisez l'IA pour les tâches de la première liste. Gardez les humains fermement en contrôle de la deuxième liste. Le gain de productivité vient de la libération des ingénieurs pour passer plus de temps sur les problèmes difficiles, pas de l'élimination complète des ingénieurs de la boucle.

Structuration des flux de travail augmentés par l'IA

Au-delà des principes, voici les modèles de flux de travail concrets que nous utilisons chez iHux :

Le modèle Specification-First

L'ingénieur écrit d'abord les signatures de type détaillées, les interfaces et les contrats de fonction. L'IA génère les implémentations. L'ingénieur examine et modifie. Cela fonctionne exceptionnellement bien pour les projets TypeScript où le système de types agit comme une spécification lisible par machine. Nous avons constaté que passer 20 minutes à écrire des types précis économise 2 heures de débogage du code généré par l'IA qui faisait de mauvaises hypothèses sur les structures de données.

Le modèle Test-First

L'ingénieur écrit les cas de test qui définissent le comportement correct. L'IA génère le code d'implémentation qui réussit ces tests. L'ingénieur examine l'implémentation pour la qualité, la sécurité et la maintenabilité. C'est essentiellement du TDD avec l'IA comme moteur d'implémentation. Cela fonctionne parce que les tests sont une forme de spécification — et écrire des tests vous force à réfléchir aux cas limites avant que le code n'existe.

Le modèle Pair Programming

Pour les fonctionnalités complexes, traitez l'IA comme un partenaire de pair programming plutôt que comme un générateur de code. Partagez votre réflexion, demandez-lui de remettre en question vos hypothèses, faites-lui suggérer des alternatives — mais prenez chaque décision vous-même. C'est le modèle le plus efficace pour les ingénieurs seniors travaillant sur des problèmes novateurs. La valeur de l'IA n'est pas le code qu'elle écrit ; ce sont les idées qu'elle soulève et les modèles qu'elle se souvient d'un vaste corpus d'entraînement.

Les pratiques d'équipe qui s'adaptent

Les pratiques individuelles ne fonctionnent que si la culture d'équipe les soutient. Voici ce que nous avons mis en place au niveau organisationnel :

• Transparence de l'IA dans les PRs. Nous marquons les parties d'une PR générées par l'IA. Non pas pour faire honte — pour assurer une profondeur d'examen appropriée. Le code généré par l'IA reçoit un examen supplémentaire sur l'architecture et la sécurité. Le code écrit par un humain reçoit un examen standard.
• Sessions hebdomadaires « comprendre votre code ». Une fois par semaine, un membre de l'équipe présente un morceau de code récemment livré et l'explique en détail. S'il a été généré par l'IA, il explique ce que l'IA a produit, ce qu'il a modifié et pourquoi. Cela renforce la compréhension partagée et détecte les problèmes cachés.
• Temps de résolution de problèmes sans IA. Nous consacrons du temps à chaque sprint pour que les ingénieurs travaillent sur des problèmes sans assistance de l'IA. Cela maintient les compétences fondamentales en résolution de problèmes et garantit que l'équipe peut fonctionner si les outils d'IA ne sont pas disponibles.
• Bibliothèques de prompts, pas de bibliothèques de code. Nous maintenons des modèles de prompts partagés pour les tâches courantes — génération de composants, rédaction de tests, intégration d'API. Cela assure une qualité cohérente et encode nos préférences architecturales dans le contexte de l'IA.

L'essentiel

Le développement assisté par l'IA n'est pas optionnel — vos concurrents l'utilisent, et l'écart de productivité est réel. Mais une adoption non structurée crée des risques qui s'accumulent en silence jusqu'à exploser lors d'un incident, d'un défi de mise à l'échelle ou d'une date limite critique pour une fonctionnalité.

Le cadre de l'ingénieur dans la boucle vous donne le meilleur des deux mondes : la vitesse de l'IA pour le travail routinier, le jugement humain pour tout ce qui compte. La clé est de traiter l'IA comme un outil qui amplifie les compétences en ingénierie — pas comme un remplacement. Les équipes qui trouvent le bon équilibre construiront de meilleurs logiciels, plus rapidement, avec moins de surprises. Les équipes qui ne le font pas livreront plus rapidement à court terme et en paieront le prix à long terme.

Investissez dans la capacité de vos ingénieurs à réfléchir, concevoir et comprendre. Ensuite, donnez-leur des outils IA pour exécuter à une vitesse surhumaine. C'est cette combinaison qui gagne.