Blog.

Pourquoi l’IA rend les bons développeurs meilleurs… et les autres dangereux

Cover Image for Pourquoi l’IA rend les bons développeurs meilleurs… et les autres dangereux
Mosaab JEBARAT
Mosaab JEBARAT

Sommaire

Un développeur peut aujourd’hui générer une API complète en quelques minutes, avec ses endpoints, sa logique métier, ses tests et même sa documentation. Le résultat est souvent impressionnant et, dans de nombreux cas, il fonctionne dès la première exécution.

Mais très vite, une question plus profonde s’impose : ce code est-il réellement compris, et surtout, est-il maîtrisé ?

Avec les agents IA, nous avons clairement gagné en vitesse d’exécution. En revanche, quelque chose de plus subtil s’est progressivement érodé : la perception du contrôle. Car l’IA possède une caractéristique fondamentale que l’on sous-estime souvent : elle ne corrige pas les faiblesses d’un système, elle les amplifie.

Ainsi, un code propre devient plus rapide à faire évoluer, plus simple à maintenir et plus agréable à manipuler. À l’inverse, un code confus ne disparaît pas sous l’effet de l’IA : il devient plus dangereux, plus opaque et plus difficile à corriger.

L’IA ne remplace donc pas le développeur ; elle agit plutôt comme un révélateur, en mettant en lumière son niveau réel.

I- L’IA n’améliore pas le code, elle l’amplifie

Les agents IA ne travaillent jamais dans le vide. Ils s’appuient systématiquement sur ce qui existe déjà dans le projet : la structure globale, les conventions de nommage, les patterns utilisés et, plus largement, tout ce qui constitue le socle du code.

C’est précisément à cet endroit que tout se joue.

🔎 Comment les agents IA “voient” ton code

Contrairement à un développeur humain, un agent IA ne navigue pas librement dans l’ensemble du projet. Il ne dispose pas d’une vision globale permanente du système. À chaque interaction, il opère dans un cadre limité, composé d’un prompt, d’un extrait de code et parfois d’un peu de documentation ou d’historique.

Tout ce qui se situe en dehors de ce périmètre est, en pratique, invisible pour lui.

Autrement dit, l’IA ne comprend jamais réellement ton système dans son ensemble. Elle reconstruit une vision partielle, basée uniquement sur les informations qu’on lui fournit à un instant donné. Cette reconstruction peut suffire à produire du code fonctionnel, mais elle reste fondamentalement fragile.

🔁 Pourquoi la qualité du code change tout

Dans un codebase propre, cohérent et bien structuré, l’IA devient rapidement un accélérateur très puissant. Les responsabilités y sont clairement définies, les noms explicites et les patterns homogènes, ce qui permet au code de “parler” presque de lui-même.

Dans ce contexte, les ambiguïtés sont réduites, les aller-retours diminuent et la compréhension s’accélère naturellement. Chaque information transmise à l’IA est utile, pertinente et directement exploitable.

À l’inverse, dès que le code devient confus, la dynamique change radicalement. Les responsabilités se brouillent, les intentions deviennent implicites et la logique métier se disperse dans différentes couches du système.

Face à cette situation, l’IA ne corrige pas les incohérences. Elle fait au mieux avec ce qu’elle perçoit, et lorsqu’il lui manque des éléments, elle comble les vides en devinant.

💸 Le vrai coût : la perte de clarté

On pourrait penser que le coût d’utilisation de l’IA est principalement lié à la taille du code ou à la complexité du projet. En réalité, ce qui pèse le plus lourd, c’est le manque de clarté.

Un code mal structuré oblige à enrichir constamment le contexte, à reformuler les demandes et à multiplier les itérations. On finit par passer plus de temps à expliquer le système qu’à le faire évoluer.

Autrement dit, ce qui consomme réellement des ressources, ce n’est pas le code lui-même, mais tout ce qu’on doit ajouter pour compenser ce qu’il n’exprime pas.

🎯 Le vrai risque : perdre le contrôle

Cependant, le problème le plus critique n’est pas le coût. Il réside dans la perte progressive de maîtrise.

Dans un environnement sain, le développeur reste en contrôle : il comprend les propositions de l’IA, les valide rapidement et les ajuste avec précision. Mais lorsque le code devient flou, cette dynamique se dégrade lentement.

On commence alors à valider sans comprendre complètement, à faire confiance parce que “cela semble correct”, et à suivre les suggestions plutôt qu’à les piloter.

C’est précisément à ce moment-là que le danger apparaît. Car un code peut parfaitement fonctionner tout en introduisant des incohérences invisibles, qui ne se révéleront que bien plus tard.

💥 À retenir

La vraie question n’est donc pas de savoir si l’IA écrit du bon code, mais plutôt de comprendre ce que ton code lui permet réellement de percevoir.

Si le code est clair, cette clarté sera amplifiée. S’il est confus, cette confusion le sera tout autant, et dans les deux cas, l’IA ira très vite.

II- Le prompt devient une compétence de développeur

Avec les agents IA, écrire du code n’est plus le seul levier de performance. La capacité à formuler une demande, à cadrer un besoin et à orienter une solution devient tout aussi déterminante.

Un agent IA n’agit pas de manière autonome au sens humain du terme. Il exécute ce qu’il comprend, et cette compréhension dépend directement de la manière dont la demande est formulée.

🎯 Un prompt n’est pas une question. C’est une spécification.

Beaucoup de développeurs utilisent encore l’IA comme un moteur de recherche amélioré, en formulant des demandes très ouvertes.

Dans ce cas, le problème n’est pas l’absence de réponse, mais le manque de précision. L’IA va naturellement combler les zones d’ombre en devinant des choix techniques, en supposant des contraintes et en inventant des comportements implicites.

Le résultat peut sembler cohérent, mais il reste souvent déconnecté du système réel.

À l’inverse, un bon prompt se rapproche d’une véritable spécification. Il explicite le contexte métier, précise les contraintes techniques, définit les règles à respecter et indique clairement ce qui ne doit pas être modifié.

Plus le cadrage est précis, plus l’IA peut raisonner correctement. À l’inverse, plus il est flou, plus elle doit interpréter, et donc potentiellement se tromper.

🧠 Guider l’IA, c’est déjà faire de l’architecture

Avec un agent IA, le rôle du développeur évolue naturellement. Il ne se contente plus d’écrire du code : il structure la manière dont le système doit être construit.

Cela implique de définir où la logique doit vivre, comment elle doit s’intégrer, ce qui est acceptable ou non, et ce qui est critique.

Ce travail existait déjà, mais avec l’IA, il devient visible. C’est précisément à cet endroit que les écarts entre développeurs se creusent : certains délèguent, tandis que d’autres pilotent.

🔌 Les connecteurs : puissants… mais pas magiques

Les connecteurs permettent d’enrichir le contexte des agents en leur donnant accès à des outils, des documents ou des discussions.

Sur le papier, cela semble idéal. Mais en pratique, plus de contexte ne signifie pas nécessairement un meilleur contexte.

Un agent connecté à tout peut récupérer des informations obsolètes, mélanger des sources contradictoires ou interpréter des éléments hors contexte.

Le résultat peut alors être moins fiable, malgré une apparente richesse d’information.

⚖️ Le vrai enjeu : signal vs bruit

Avec l’IA, la question n’est pas simplement de savoir si l’on dispose de suffisamment de contexte, mais plutôt si ce contexte est pertinent, structuré et exploitable.

Un bon développeur ne cherche pas à tout transmettre. Il cherche à transmettre juste ce qu’il faut pour permettre un raisonnement correct.

Filtrer, structurer, hiérarchiser et simplifier deviennent alors des compétences clés.

💥 À retenir

Un agent IA dépend entièrement de ce qu’on lui donne.

Un mauvais développeur peut produire du mauvais code, mais un mauvais prompt peut produire un mauvais système entier.

À l’inverse, un bon développeur ne se contente pas d’utiliser l’IA : il sait la cadrer.

III- Trop de contexte tue le contexte

Face aux limites des agents IA, la réaction naturelle est presque instinctive : leur donner davantage de contexte. On ajoute plus de code, plus de documentation, plus d’historique, plus de données, avec l’idée que plus l’IA dispose d’informations, mieux elle comprendra.

Sur le papier, ce raisonnement tient parfaitement. Si l’IA raisonne à partir du contexte qu’on lui fournit, alors lui donner “tout” semble être la meilleure stratégie.

Mais en pratique, cela ne fonctionne pas ainsi.

⚠️ Le piège : plus d’information ≠ meilleure compréhension

Un agent IA ne traite pas l’information comme un humain. Là où un développeur va naturellement hiérarchiser, prioriser et contextualiser, l’IA, elle, applique un traitement beaucoup plus uniforme.

Elle ne priorise pas spontanément ce qui est important, ne distingue pas toujours le signal du bruit et ne sait pas forcément identifier ce qui est obsolète, critique ou secondaire. En réalité, elle traite l’ensemble des informations qu’on lui fournit avec un poids relativement équivalent.

Ce fonctionnement entraîne rapidement des effets inattendus : des informations contradictoires peuvent coexister sans être résolues, des décisions anciennes peuvent influencer des réponses actuelles et des détails secondaires peuvent masquer des éléments essentiels.

Au lieu d’améliorer la qualité du raisonnement, on introduit progressivement de la confusion.

🧠 L’illusion du contexte complet

Donner beaucoup de contexte crée une forme de confort. On a l’impression que l’IA dispose de tout ce dont elle a besoin pour prendre les bonnes décisions.

“Elle a tout sous les yeux, donc elle va forcément faire le bon choix.”

Mais cette impression est trompeuse.

En réalité, l’IA ne “voit” jamais parfaitement l’ensemble du système. Elle reconstruit une compréhension à partir d’un ensemble de signaux, parfois incomplets, parfois incohérents, et souvent mal hiérarchisés.

Plus ces signaux sont nombreux et désorganisés, plus l’interprétation devient fragile. C’est précisément dans ces situations que les hallucinations apparaissent : des réponses plausibles mais incorrectes, des liens logiques inventés et des décisions basées sur des hypothèses implicites.

🔁 Quand la mémoire devient un problème

Les systèmes de type RAG ou les mémoires partagées apportent pourtant une valeur immense. Ils permettent de capitaliser sur l’expérience, de retrouver des solutions passées, d’enrichir le contexte des agents et d’éviter de repartir de zéro à chaque interaction.

Mais mal maîtrisés, ils introduisent un nouveau risque : celui d’accumuler de la connaissance sans réellement la structurer.

Une mémoire non contrôlée peut rapidement contenir des solutions obsolètes, des pratiques contradictoires, des contextes incomplets ou des décisions sorties de leur environnement initial. Et dans ce cas, l’IA peut s’appuyer sur ces informations sans faire de distinction.

La richesse de la mémoire devient alors une faiblesse.

⚖️ Le vrai enjeu : filtrer, structurer, contextualiser

Le problème n’est donc pas d’avoir beaucoup d’information, ni même d’avoir une mémoire riche. Le véritable enjeu réside dans la capacité à contrôler ce qu’on en fait.

Avec l’IA, la qualité du contexte devient aussi critique que la qualité du code lui-même. Cela implique de filtrer les informations pertinentes, de structurer la connaissance, de versionner les pratiques, de contextualiser les décisions et d’éliminer le bruit inutile.

Autrement dit, une bonne mémoire ne consiste pas à tout stocker. Elle consiste à conserver ce qui est utile, compréhensible et exploitable.

💥 À retenir

Ajouter du contexte ne rend pas l’IA plus intelligente. Cela la rend simplement plus dépendante de la qualité de ce contexte.

Lorsqu’elle manque d’information, elle comble les vides en devinant. Lorsqu’elle en reçoit trop, elle se perd dans le bruit.

L’équilibre se situe ailleurs : il consiste à fournir juste assez de contexte pour permettre un raisonnement correct, sans noyer l’IA dans une masse d’informations inutiles.

IV- De l’outil individuel à l’agent d’équipe

Utiliser un agent IA seul dans son coin reste relativement simple. On expérimente, on teste, on ajuste ses prompts et, dans ce cadre, chacun trouve rapidement ses repères. Mais dès que l’on cherche à intégrer ces agents dans une équipe de développement, la situation change complètement.

Si chaque développeur utilise Claude Code, Codex ou tout autre agent avec ses propres habitudes, ses propres prompts et sa propre compréhension du projet, la divergence apparaît presque immédiatement. Chacun va effectivement plus vite, mais pas nécessairement dans la même direction, ce qui fragilise progressivement la cohérence du système.

Dans ce contexte, le véritable enjeu ne consiste pas seulement à disposer d’un agent IA performant. Il s’agit surtout de lui donner un cadre commun, partagé par toute l’équipe, afin que cette accélération reste maîtrisée.

🧠 Donner un contexte commun à l’IA

Pour répondre à ce besoin, nous avons commencé par formaliser ce cadre directement dans les repositories. Chaque projet est ainsi piloté par un fichier d’instructions, souvent nommé AGENTS.md, CLAUDE.md ou équivalent, qui joue le rôle d’un prompt système propre au projet.

Ce fichier ne se limite pas à quelques indications générales. Il décrit en profondeur le contexte métier, l’architecture globale, les conventions techniques, les règles d’écriture du code, les patterns à respecter, les bonnes pratiques de tests ainsi que les processus à suivre selon les types de tâches.

L’objectif est d’éviter que l’agent démarre sans contexte, mais aussi de rendre cette connaissance explicite. Elle n’est plus enfermée dans des prompts individuels ; elle est versionnée avec le code, visible par tous et améliorable collectivement.

⚙️ Descendre le contexte au bon niveau

Cependant, un fichier global ne suffit pas à couvrir la complexité d’un système réel. Tous les modules ne répondent pas aux mêmes contraintes, et il serait contre-productif d’imposer un cadre uniforme à des parties du système qui n’ont pas les mêmes besoins.

Un backend, un frontend, une couche d’accès aux données ou un module métier ne se conçoivent pas de la même manière. C’est pourquoi nous avons progressivement structuré les instructions par niveau : un contexte global à la racine, complété par des règles spécifiques à chaque sous-projet, puis affiné par des contraintes adaptées à certains répertoires ou types de composants.

L’objectif n’est pas d’accumuler des règles, mais de fournir à l’agent le bon contexte, au bon endroit. Lorsqu’il intervient sur un module, il doit comprendre ce module en profondeur, sans être noyé dans des informations qui ne le concernent pas directement.

🧩 Introduire des skills réutilisables

Au-delà des instructions, une autre brique devient rapidement essentielle : les skills.

Un skill ne correspond pas à une simple documentation. Il s’agit d’une capacité directement exploitable, qui décrit une manière de faire dans un contexte donné. Là où une documentation explique, un skill guide l’action.

Concrètement, un skill peut couvrir des situations très variées : créer un endpoint conforme aux standards du projet, écrire un test unitaire structuré, implémenter une logique métier spécifique, gérer une migration de données ou encore diagnostiquer un problème récurrent.

Pour être réellement utile, un skill intègre généralement le contexte dans lequel il s’applique, les étapes à suivre, les conventions à respecter, les erreurs à éviter et, lorsque cela est pertinent, des exemples concrets.

🔁 Transformer l’expérience en capacité

Avant l’introduction de ces skills, ce type de connaissance restait souvent implicite. Elle vivait dans la tête des développeurs, dans des discussions informelles ou se perdait dans des tickets.

Avec cette approche, on change de niveau. Une expérience vécue ne reste plus isolée : elle devient une capacité réutilisable par l’ensemble de l’équipe et par les agents IA.

Un développeur n’a plus besoin de reformuler systématiquement une manière de faire. Il peut s’appuyer sur un cadre validé. De son côté, l’agent ne cherche plus à deviner : il applique une méthode connue.

🤝 Aligner l’équipe autour de l’IA

Ce système produit rapidement des effets visibles sur le travail en équipe. Il permet d’aligner les pratiques, de limiter les divergences, de standardiser les tâches complexes et de capitaliser à la fois sur les erreurs et sur les réussites.

Au lieu d’avoir une multiplicité d’approches individuelles, on construit progressivement un socle commun. Les développeurs continuent d’avancer rapidement, mais cette vitesse s’inscrit désormais dans une direction partagée.

L’IA cesse alors d’être un outil purement individuel pour devenir un véritable levier collectif.

💥 À retenir

Intégrer un agent IA dans une équipe ne consiste pas simplement à autoriser son utilisation. Cela implique de lui fournir un cadre clair, composé d’un contexte, de règles, de limites, de processus et de capacités réutilisables.

Les instructions définissent l’environnement dans lequel l’agent évolue, tandis que les skills définissent la manière d’agir dans cet environnement.

Mais surtout, ces éléments doivent vivre avec le code. Ils doivent être versionnés, partagés et enrichis en continu.

Car un agent IA apprend un projet comme un développeur : à travers ses règles, son architecture et son historique. La différence, c’est qu’avec l’IA, ce qui n’est pas explicitement écrit n’existe pas réellement.

V- Vers une mémoire partagée entre humains et agents IA

Dans notre cas, nous avons rapidement ressenti les limites d’un simple cadre d’utilisation de l’IA. Les instructions et les skills apportaient déjà beaucoup de structure, mais il manquait encore un élément essentiel pour créer une véritable continuité dans la compréhension du projet.

Nous avons donc expérimenté une approche complémentaire : mettre en place une mémoire partagée, directement connectée aux agents.

L’objectif n’était pas de créer une base de connaissance supplémentaire, ni d’ajouter une couche documentaire de plus. Il s’agissait plutôt de construire un point de convergence entre les équipes… et les agents IA, afin que tous s’appuient sur une même source de compréhension.

🧠 Une mémoire commune, au-delà des développeurs

Cette mémoire est intégrée directement dans les prompts systèmes et dans les skills, ce qui la rend naturellement accessible aux agents, sans effort particulier. Mais son rôle dépasse largement le cadre technique.

Elle ne concerne pas uniquement les développeurs. Elle est utilisée par les product owners, les équipes de recette, le support et, plus largement, par toute personne ayant besoin de comprendre le système.

Parce qu’elle peut être connectée à des interfaces comme ChatGPT, Claude ou d’autres outils, elle devient progressivement un point d’entrée unique pour interroger le projet, quel que soit le profil de l’utilisateur.

🔁 Changer la manière dont l’IA comprend le projet

Sans ce type de mémoire, un agent IA fonctionne le plus souvent de manière exploratoire. Il parcourt le code, tente de reconstruire la logique métier et cherche des indices pour comprendre ce qu’on attend de lui.

Avec une mémoire partagée, la dynamique change profondément.

L’agent ne part plus uniquement du code. Il accède directement au contexte métier, à l’historique des décisions, aux évolutions du projet, aux liens entre fonctionnalités et aux problèmes déjà rencontrés.

Autrement dit, il ne découvre plus le système étape par étape. Il commence déjà avec une compréhension structurée de celui-ci.

📚 Une mémoire vivante

Un point clé de cette approche réside dans le fait que cette mémoire n’est pas statique. Elle évolue en permanence, au rythme du projet et des interactions.

Lorsqu’un développement est réalisé, l’agent est encouragé à enrichir cette mémoire en ajoutant du contexte, en documentant des décisions, en reliant une implémentation à un besoin ou en traçant un enchaînement fonctionnel.

On passe ainsi d’une documentation passive, rarement consultée et souvent obsolète, à une mémoire active, constamment mise à jour et directement exploitable.

🔄 Coupler la mémoire et les skills : vers une intelligence collective

Une fois cette mémoire en place, une étape supplémentaire transforme profondément son impact : y intégrer les skills.

Au lieu d’être isolés, les skills deviennent partagés, accessibles et versionnés au sein de cette mémoire commune. Tous les agents s’appuient alors sur les mêmes méthodes pour travailler, ce qui renforce naturellement la cohérence globale.

Mais surtout, ces skills ne restent plus figés. Ils deviennent évolutifs, capables de s’enrichir au fil des usages et des retours.

🧠 Des skills qui apprennent

Prenons un exemple simple.

Un agent utilise un skill pour traiter une commande selon une logique bien définie. Dans la majorité des cas, cette approche fonctionne. Mais lorsqu’un cas particulier apparaît, le skill montre ses limites.

C’est à ce moment-là que l’intervention humaine devient déterminante. Le développeur ou l’expert métier guide l’agent, précise le contexte spécifique et ajuste le raisonnement.

Une fois le problème résolu, le skill est enrichi avec ce nouveau cas.

La prochaine fois qu’une situation similaire se présente, l’agent ne repart pas de zéro. Il applique directement une version améliorée du skill, intégrant cette nouvelle connaissance.

🤝 Une mémoire alimentée par toute l’équipe

Ce mécanisme dépasse largement le cadre technique.

Un développeur peut améliorer un skill technique, un product owner peut enrichir un cas métier, un testeur peut ajouter des scénarios de validation et le support peut intégrer des cas réels issus du terrain.

Chaque interaction devient une opportunité d’apprentissage, et cette connaissance n’est plus isolée. Elle est immédiatement partagée et rendue accessible à l’ensemble du système.

🔗 Relier les équipes et les usages

Cette mémoire permet également de recréer des liens entre les différentes étapes du projet.

À partir d’une simple question, il devient possible de remonter toute la chaîne : comprendre le besoin initial, voir ce qui a été analysé, suivre ce qui a été développé et accéder aux éléments techniques associés.

On peut ainsi reconstruire un enchaînement complet, du besoin jusqu’au résultat final, en passant par l’analyse, le développement et les tests.

L’agent gagne alors une vision globale du cycle de vie, ce qui améliore considérablement sa capacité à raisonner correctement.

🎯 Impact sur la qualité

Les effets de cette approche sont rapidement visibles.

La compréhension des besoins s’améliore, le développement devient plus cohérent, la documentation reste alignée avec la réalité du système et les tests gagnent en pertinence.

La communication entre les équipes devient également plus fluide, car chacun s’appuie sur une base commune.

Mais surtout, l’écart entre ce qui est demandé, ce qui est développé et ce qui est livré se réduit significativement.

💥 À retenir

Une mémoire partagée ne sert pas simplement à stocker de l’information. Elle permet de donner du contexte aux agents, d’aligner les équipes, de capitaliser sur l’expérience et de faire évoluer les pratiques en continu.

Mais le véritable levier réside dans le couplage entre mémoire et skills.

Dans ce modèle, les agents utilisent les mêmes méthodes, ces méthodes s’améliorent progressivement et chaque interaction enrichit le système pour l’ensemble des utilisateurs.

L’IA ne travaille alors plus uniquement sur du code.

Elle s’appuie sur une compréhension vivante du projet.

Conclusion: L’IA ne change pas le niveau, elle le révèle

Les agents IA ont transformé la manière de développer, mais ils n’ont pas supprimé les fondamentaux.

Produire du code est devenu facile, mais produire un système cohérent reste difficile.

Avec l’IA, la différence entre développeurs ne disparaît pas : elle s’amplifie.

Les équipes qui réussiront seront celles qui sauront structurer son usage et capitaliser sur la connaissance.

L’IA n’accélère pas seulement le développement.

👉 Elle accélère les conséquences des décisions.

À lire aussi