L’IA transforme le système d’ingénierie, pas seulement le poste de développeur

Si l’intelligence artificielle est désormais intégrée dans l’écosystème quotidien des développeurs, l’illusion la plus répandue consiste à croire qu’il suffit de fournir de bons prompts pour décupler la productivité d’une équipe. Pourtant sur le terrain l’adoption massive des LLM révèle une réalité bien différente : l’IA ne modifie pas seulement le geste individuel d’écriture de code. Elle instaure une véritable démarche de développement augmenté, où c’est le système d’ingénierie dans son ensemble (pipelines CI/CD, garde-fous automatisés) qui est accéléré. Si le système est flou, elle accélère le flou. S’il est cadré, elle démultiplie la valeur produite.

Mathieu Defianas, expert DevOps et responsable du centre d’Excellence Digital Hub chez Inside, nous explique pourquoi le sujet n’est pas l’outil, mais le cadre d’ingénierie qui l’entoure, et comment poser les bons garde-fous pour accélérer en toute confiance.

Le débat actuel se focalise beaucoup sur la vitesse d’écriture du code. Est-ce le bon prisme pour évaluer l’impact de l’IA ?

L’outil n’est pas le sujet principal. Le vrai sujet, c’est le système d’ingénierie qui est autour. Aujourd’hui, les développeurs utilisent largement l’IA, mais seule une minorité accorde une confiance aveugle au code produit. Pourquoi ? Parce qu’un modèle de langage est conçu pour générer ce qui est statistiquement plausible, pas ce qui est factuellement vérifié.

Et c’est précisément cette capacité à générer massivement du code non garanti qui agit comme un révélateur. L’IA n’améliore donc pas magiquement une équipe : elle amplifie ce qu’elle est déjà. Une équipe dotée de pratiques craft solides (tests, intégration continue, revues exigeantes…) devient nettement plus efficace pour filtrer et exploiter ce volume. En revanche, une équipe fragile voit ses problèmes d’architecture et de dette technique décuplés. L’accélération ressentie au moment du prompt crée un embouteillage massif au moment de la revue de code si le système n’est pas armé pour vérifier ce qui est produit.

L’IA augmente le volume de changements plausibles. Par conséquent, elle n’augmente pas seulement la vitesse, elle augmente la valeur des preuves.

Quelle est la véritable valeur du prompt dans ce contexte ?

Si un meilleur prompt aide, il ne remplace jamais un système d’ingénierie. Certes, préciser un rôle, une tâche ou un format dans un prompt reste une consigne. Mais cela ne remplace ni les tests, ni l’intégration continue, ni les linters, ni la connaissance métier, ni la responsabilité humaine au moment du merge.

Le vrai levier ne se trouve pas dans l’artifice du prompt, mais dans le contexte projet, les conventions d’équipe et la lisibilité du code généré. Donner le bon contexte vaut d’ailleurs beaucoup mieux que donner tout le contexte. Inonder un modèle avec l’intégralité d’un dépôt génère du bruit, augmente le risque d’hallucinations et alourdit la charge de vérification.

Par exemple, pour rendre un projet lisible par une IA sans compromettre la sécurité ni surcharger la fenêtre de contexte, les équipes peuvent mettre en place un context pack (souvent matérialisé par un fichier AGENTS.md ou AI_CONTEXT.md à la racine du dépôt). Ce document réunit l’essentiel de manière synthétique et ciblée : architecture, conventions de nommage, stack et règles d’exécution. Loin d’être figé, il est versionné, vit avec le code et fait l’objet de revues au même titre qu’un fichier de configuration CI ou une ADR (Architecture Decision Record). Enfin, il se révèle tout aussi utile aux IA qu’aux humains en contenant les commandes de test et de build, ainsi que la liste des pièges connus du projet. 

Un context pack bien conçu permet à l’IA de proposer un plan d’action pertinent avant toute modification, tout en servant de guide d’embarquement idéal pour les nouveaux développeurs qui rejoignent l’équipe.

Comment faire évoluer les pratiques de développement pour éviter le phénomène d’AI Slop ou de code non maîtrisé ?

La clé réside dans le déplacement des garde-fous plus tôt dans la chaîne. Tout commence avant même de formuler une requête à l’IA, en définissant un besoin strictement borné et en s’assurant qu’aucune donnée sensible ou identifiant ne quitte le cadre sécurisé de l’organisation. 

Ensuite, vient l’étape de conception : avant d’écrire la moindre ligne de code, l’IA doit d’abord soumettre un plan d’action court détaillant les fichiers qu’elle compte impacter, que l’humain doit impérativement valider. 

Enfin, la phase de validation ne tolère aucun compromis. Avant d’être fusionné, le code produit par le modèle doit franchir exactement les mêmes barrières de qualité que s’il avait été écrit à la main, qu’il s’agisse des linters, des tests automatisés ou des analyses de sécurité.

L’IA prépare le terrain, mais l’humain reste le seul véritable décideur. Si l’assistant se révèle particulièrement précieux pour relire les modifications, identifier des cas d’usage oubliés ou suggérer des tests unitaires complémentaires, il ne signe jamais la Pull Request.

Je ne donne jamais le pouvoir de merger à l’IA. Son usage mature est sobre, borné, vérifiable et réversible.

Une équipe mature peut-elle dire stop à l’IA ?

La maîtrise technique inclut la capacité d’appliquer des règles de stop. Par exemple, nous appliquons une règle simple : si après deux itérations l’IA n’améliore pas clairement le résultat, on arrête la boucle. Reprendre la main, repasser sur un outil déterministe (un refactor d’IDE, un grep, un linter), ou échanger entre pairs est souvent bien plus efficace que de s’entêter dans un dialogue stérile avec un modèle.

De même, si l’IA commence à ajouter des dépendances non demandées, à modifier des jeux de données de test ou à proposer des changements d’architecture implicites, la consigne doit être de stopper immédiatement la boucle agentique pour isoler le problème.

Voici une grille qui aide à cadrer la démarche de l’IA :

1. Autorisé ? (Classification des données, outils validés, souveraineté).
2. Qualité ? (Garde-fous non négociables, couverture de tests).
3. Contexte ? (Minimum utile fourni via le context pack).
4. Capacités ? (Distinguer la lecture, la modification et les droits d’exécution).
5. Compétences ? (Savoir cadrer, vérifier, expliquer et savoir renoncer).
6. Cas d’usage ? (Cibler des irritants précis et mesurables, pas un usage indistinct).
7. Mesure ? (Suivre l’adoption et la qualité nette apportée).

Comment Inside accompagne les équipes vers cette démarche augmentée ?

Chez Inside, nous abordons l’IA sous l’angle du génie logiciel et de la culture d’ingénierie. Nous aidons nos clients à structurer ce cadre de confiance et à faire évoluer leurs pratiques de delivery vers un modèle pérenne de développement augmenté, où l’IA s’intègre harmonieusement aux processus d’intégration et de déploiement continus. Concrètement, l’apprentissage ne se fait pas en regardant des présentations théoriques, mais en pratiquant sur le vrai code des projets. 

Nous privilégions des formats en atelier, comme le mob programming guidé, où les équipes apprennent à borner une demande, à manier le context pack, à challenger les retours de revue automatisés et à définir leurs propres règles de stop. L’objectif est de préserver le savoir-faire craft des équipes tout en leur permettant de tirer le meilleur parti de l’accélération offerte par l’IA.