Lorsque j’ai commencé à utiliser l’intelligence artificielle dans le développement logiciel, une tendance a rapidement fait surface dans ma façon de travailler. Je passais mon temps à répéter nos standards de programmation à chaque nouvelle session pour m’assurer qu’elle produise une solution satisfaisante.
En discutant avec des collègues, j’ai réalisé que je n’étais pas seul. Eux aussi vivaient les mêmes frustrations! J’ai même entendu l'un d'eux dire : « Je passe plus de temps à corriger ce que l'IA me propose qu'à coder moi-même. Elle ne fait jamais exactement ce que je veux! »
C’est un constat largement partagé au sein de la communauté. Pour ceux et celles qui commencent à explorer l’IA et ses capacités, il est crucial de comprendre un élément fondamental des modèles actuels : l’IA n’apprend pas.
Que vous soyez développeur.euse, gestionnaire de produit ou designer, cette réalité reste vraie et va changer votre façon de collaborer avec elle. Voyons comment l’IA fonctionne conceptuellement et comment nous pouvons l’aider à respecter nos pratiques de travail.
Pour comprendre la source de nos frustrations, il faut d'abord casser une illusion tenace : l'IA ne « comprend » pas ce qu'elle fait. Des outils comme ChatGPT ou Claude sont, fondamentalement, des moteurs statistiques extrêmement sophistiqués. Leur travail consiste à prédire le mot suivant le plus probable en fonction de ce que vous venez de taper. C'est du calcul, pas de la réflexion.
Cette nature probabiliste amène un deuxième problème majeur : l'amnésie. Imaginez un collègue brillant qui aurait lu toute la documentation du monde, mais qui perdrait complètement la mémoire à chaque fois qu'il franchit la porte de votre bureau. Pendant votre discussion, il est incroyable. Il s'adapte à vos remarques, corrige son tir et donne l'impression d'apprendre. Mais dès que vous fermez la fenêtre et ouvrez une nouvelle conversation, il repart de zéro. Il a tout oublié de vos préférences, de l'architecture de votre projet ou des erreurs qu'il a corrigées la veille. Sa seule mémoire, c'est l'historique de la conversation en cours.
Puisqu'elle repart d'une page blanche à chaque fois, l'IA adopte un comportement par défaut : elle vise le milieu. C'est le problème du 50e percentile. Sans contexte spécifique sur votre façon de travailler, elle va générer la réponse la plus statistiquement probable basée sur ses données d'entraînement. Vous lui demandez de générer du code? Elle utilisera les patterns les plus courants d'Internet, pas forcément ceux que votre équipe a mis des mois à standardiser. Elle ne sera jamais vraiment mauvaise, mais jamais excellente non plus.
En résumé, l'IA retient bien le contexte immédiat de votre discussion actuelle, mais elle oublie systématiquement tout le reste. Et même cette mémoire à court terme a ses limites : si votre conversation s'éternise ou que vous lui fournissez trop de fichiers d'un coup, elle atteint la limite de sa "fenêtre de contexte". Pour continuer à fonctionner, elle va commencer à compresser l'historique ou à « oublier » certaines informations que vous lui aviez données. La qualité de ses réponses va alors se dégrader.
Sans intervention de votre part pour structurer cette mémoire, elle restera éternellement bloquée dans cette moyenne générique ou finira par s'y perdre.
C'est ici qu'il faut faire une distinction fondamentale que beaucoup d'entre nous confondent au début : la différence entre la mémoire intra-session et la mémoire inter-session.
Dans le feu de l'action, l'illusion est parfaite. L'IA lit le contenu des fichiers que vous lui donnez, suit les instructions de votre prompt et saisit le contexte immédiat de votre question. Si vous la corrigez sur un point, elle s'ajuste pour la suite de la discussion. C'est ce qu'on appelle la mémoire intra-session. Elle retient absolument tout ce qui se passe dans la conversation en cours. Mais c'est temporaire. Ça disparaît dès que la session se termine.
Le problème survient quand on ferme l'onglet. C'est là que la mémoire inter-session devrait prendre le relais pour conserver l'information d'une discussion à l'autre.
Dans les derniers mois, les outils comme ChatGPT, Gemini et Claude ont commencé à intégrer des fonctionnalités de mémoire inter-sessions. Celles-ci servent à garder certaines informations de conversations précédentes. Quelle information est enregistrée dans cette mémoire? C’est à la discrétion de l’outil. Vous ne savez jamais vraiment ce que l'IA a retenu, ce qu'elle a oublié ou comment elle l'interprète. Les fichiers restent cependant disponibles sur votre ordinateur.
Malgré cela, à chaque nouvelle session, l'IA a tendance à repartir de zéro, de son fameux 50e percentile générique. Sauf, bien sûr, si vous prenez le contrôle et que vous construisez cette mémoire vous-même de façon explicite.
Mais si on laisse l'IA à elle-même, que se passe-t-il quand on l'utilise sans tenir compte de cette amnésie?
Quand on ignore les limites de la mémoire de l'IA, on présume à tort qu’elle garde en tête toute la complexité de notre projet. On tombe facilement dans un piège que l'on appelle de plus en plus le vibe coding. Le concept est simple : on décrit vaguement ce qu'on veut, l'IA pond du code, on l'accepte sans vraiment chercher à le comprendre et on passe à la suite.
On a tous vu ces histoires en ligne de personnes sans bagage technique qui sortent des applications entières de cette façon. Le problème, c'est que le résultat peut manquer d’éléments primordiaux dans le développement tel que la sécurité. De plus, dès qu'il faut maintenir le projet, tout s'effondre. Si l’IA n’est pas capable de résoudre un bogue, que se passe-t-il? L'IA a beau connaître les règles de sécurité, si on ne la guide pas explicitement vers notre contexte, elle ne les appliquera pas par défaut.
Le vibe coding n'est pas mauvais en soi. Pour faire une preuve de concept, tester une idée rapidement ou visualiser un prototype, c'est un raccourci précieux. Mais essayer d'en faire un produit final sans l'expertise nécessaire pour valider le code, c'est aller droit dans le mur.
C'est là qu'on risque de diluer notre propre savoir-faire. Vous connaissez l'histoire du designer qui facture 5 000 $ pour un logo dessiné en cinq minutes sur une serviette en papier? Au client indigné, il répond qu'il facture en réalité ses vingt ans d'expérience qui lui permettent d'aller aussi vite.
Avec l'IA, on risque d'inverser cette logique. Si la machine génère tout votre code et que vous ne comprenez plus le cheminement derrière, le savoir-faire reste enfermé dans l'outil. Votre base de code devient une boîte noire que plus personne dans l'équipe ne maîtrise vraiment. Au final, le résultat de l'IA est toujours à la hauteur de la personne qui l'utilise. Sans expertise pour guider et corriger, on se contente d'un travail moyen et on perd peu à peu notre capacité à faire mieux.
Comment savoir si on a franchi la ligne de la délégation aveugle? Il y a des signes qui ne trompent pas. Le premier, c'est quand vous devenez incapable d'expliquer à un.e collègue le code que vous venez d'intégrer. Un autre symptôme classique est de se retrouver à demander exactement la même chose à chaque nouvelle session. L'IA a oublié ; vous recommencez depuis le début, et le temps soi-disant gagné est perdu en répétition.
Pire encore, accepter le premier résultat sans le relire transforme cette fausse impression de vitesse en une dette technique massive. Si une fonctionnalité entière a été générée de cette façon et que le contexte n'a pas été documenté, la moindre maintenance future va se transformer en véritable fouille archéologique pour le reste de l'équipe.
Heureusement, ces pièges ne sont pas une fatalité. Ils se corrigent en changeant simplement notre façon d'interagir avec l'outil au quotidien.
Dans mon expérience, la tentation est grande de demander à l'IA de produire beaucoup de code ou de contenu d'un seul coup. J'ai moi-même passé des semaines à corriger inlassablement les mêmes erreurs avant de réaliser que le problème n'était pas l'outil. Le problème, c'était que je ne documentais rien. Plus la tâche que vous lui confiez est large, plus le résultat sera générique et éloigné de ce dont vous avez réellement besoin.
Dans le fond, c'est exactement la même philosophie que le développement de produit classique. Quand on construit un logiciel, on ne code plus pendant six mois dans son coin avant de le montrer aux clients. On y va par petites itérations, on livre une fonctionnalité, on observe comment les utilisateurs réagissent et on s'adapte.
Travailler avec l'IA demande exactement la même dynamique. Au lieu de demander une fonctionnalité complète, allez-y par itérations :
Ce rythme a un double avantage : il maintient votre propre compréhension du code à jour et limite drastiquement la dérive de qualité. Chaque cycle de feedback devient une occasion de recadrer l'IA avant qu'elle ne s'éloigne trop de votre vision.
C'est là qu'entre en jeu ce que j'appelle la correction active. Je me suis fixé une règle simple : si je corrige la même chose plus d'une fois, c'est le signal qu'il faut l'ajouter à mes fichiers de configuration.
À chaque fois que vous corrigez l'IA, posez-vous la question si vous pouvez faire en sorte qu'elle ne refasse plus jamais cette erreur. Si la réponse est oui, c’est le moment d’agir. Vous ne faites pas que corriger un problème ponctuel ; vous prévenez toutes les occurrences futures. C'est exactement ce qui fait le pont entre un simple ajustement et la construction d'une mémoire durable.
Prenons un exemple concret. Vous demandez à l'IA de créer une fonction utilitaire en TypeScript. Elle produit un code qui fonctionne, mais qui est truffé de any, sans aucun typage fort. Vous corrigez manuellement les types. Au lieu de vous arrêter là, vous vous demandez comment éviter que cela se reproduise. Vous ajoutez alors une règle dans votre fichier de configuration IA lui indiquant de toujours utiliser des types explicites en TypeScript et de ne jamais utiliser any. À la session suivante, le code sera fortement typé dès le départ. Vous venez de transformer une correction éphémère en amélioration permanente.
Faire des retours ponctuels à la machine, c'est bien. Mais pour que ces corrections survivent au-delà de la session en cours, il faut absolument les ancrer quelque part.
La mémoire automatique de l'IA reste capricieuse. Comme on ne contrôle ni ce qu'elle décide de retenir, ni comment elle va l'utiliser, la seule vraie solution pour du développement logiciel est de lui construire une mémoire artificielle sur mesure. Le principe est d'écrire vos conventions, vos décisions et vos préférences dans des fichiers que l'outil va lire automatiquement. Pour la machine, ces fichiers deviennent sa source de vérité absolue.
Concrètement, ça commence par un simple fichier de configuration à la racine de votre projet. Selon l'outil que vous utilisez, cela peut être un CLAUDE.md, un .cursorrules ou un équivalent. Ce fichier texte est versionné dans votre dépôt et l'IA le lit au début de chaque conversation. Vous y inscrivez vos conventions d'équipe, vos décisions architecturales et vos règles de code. C'est le levier le plus simple et le plus puissant à votre disposition. À chaque nouvelle session, l'IA démarre avec votre contexte plutôt qu'avec le sien.
Vous pouvez ensuite aller plus loin. Au-delà du projet, il est possible de configurer des préférences globales (la langue, le ton, des conventions de nommage génériques) qui s'appliqueront à toutes vos sessions. Certains outils permettent même à l'IA de prendre ses propres notes en cours de route pour capter ce que vous auriez oublié de documenter.
Pour les utilisateurs plus avancés, cette personnalisation se transforme en véritable automatisation. Avec le concept de "skills" (ou compétences), vous découpez votre savoir en modules spécialisés. Si l'IA doit écrire des tests par exemple, elle charge automatiquement votre module dédié aux conventions de tests. Si elle génère un composant, elle consulte votre module d'architecture front-end. Au lieu d'avoir un fichier fourre-tout gigantesque, vous constituez une bibliothèque de savoirs dans laquelle l'outil pioche au bon moment.
Les agents personnalisés poussent cette logique encore plus loin. Au lieu d'utiliser une seule IA généraliste qui jongle avec un contexte immense, vous créez des spécialistes. Vous pouvez avoir un agent rédacteur de tests calibré sur vos patterns et un autre dédié à la revue de code avec vos critères de qualité stricts. Chacun possède son propre contexte ciblé et sa propre mémoire. C'est toute la différence entre utiliser un couteau suisse et faire appel à une équipe d'artisans.
Mais peu importe le niveau de complexité, le principe de base reste le même : il n'y a pas de magie. Ce ne sont que des fichiers texte, versionnés et lisibles par un humain, que l'IA consulte avant de se mettre au travail.
Prenons un exemple technique concret. Souvent, l'IA génère des tests en créant des objets manuellement à chaque fois. Vous vous retrouvez avec des dizaines de lignes de configuration dupliquées où chaque test reconstruit un utilisateur ou une commande avec tous ses champs, même ceux qui ne servent à rien pour le cas testé.
Pour corriger ça, il suffit d'ajouter ces quelques lignes de markdown directement dans votre fichier CLAUDE.md ou .cursorrules :
## Tests
- Utiliser des fonctions fixture pour créer les objets de test
- Chaque fixture fournit des valeurs par défaut et accepte un Partial<T> pour les overrides
- Ne spécifier dans le test que les champs pertinents au cas testé
function createUser(props: Partial<User> = {}): User {
return {
id: "user-1",
name: "Alice",
email: "alice@example.com",
role: "developer",
...props,
};
}
// Dans le test : seul le champ pertinent est spécifié
const admin = createUser({ role: "admin" });
Le résultat est immédiat. Les tests générés utiliseront ces fonctions dès le départ. Vous aurez moins de duplication, des tests plus lisibles et une intention claire. D'ailleurs, pour aller plus loin sur l'écriture de tests orientés comportement avec l'IA, je vous invite à consulter notre article dédié sur le sujet.
Ce concept s'applique tout aussi bien en dehors du code. Si l'IA rédige des récits utilisateur avec des critères d'acceptation beaucoup trop vagues du style "l'utilisateur devrait pouvoir...", il suffit d'ajouter une règle claire dans votre configuration :
## Rédaction de stories
- Toujours utiliser le format Given/When/Then pour les critères d'acceptation
- Inclure au minimum un cas nominal et un cas d'erreur
- Référencer le persona concerné
Dès la session suivante, vos stories deviendront directement exploitables. Le format restera cohérent d'une discussion à l'autre, sans que vous n'ayez besoin de le rappeler à chaque fois.
Le processus est simple et cumulatif :
Correction manuelle → Mise à jour du fichier de config → Vérification → ✓ (ou retour à l'étape 1)
Chaque règle ajoutée rend l'IA un peu plus adaptée à votre contexte. C'est un processus simple et cumulatif. Vous faites une correction manuelle, vous mettez à jour le fichier de configuration, vous vérifiez que ça fonctionne, et la boucle est bouclée. Au fil des semaines, votre assistant ne démarre plus du 50e percentile générique. Il démarre avec vos choix et vos préférences. La seule différence entre un assistant banal et un assistant parfaitement calibré pour votre projet, c'est ce fichier de configuration et la discipline que vous mettez à le maintenir à jour.
Il faut tout de même garder en tête que ces fichiers ne sont pas une solution miracle. Ils demandent de la maintenance. Un fichier qui n'est pas révisé régulièrement va accumuler des instructions contradictoires ou dépassées. Il faut aussi se méfier du faux sentiment de contrôle. L'IA peut très bien ignorer ou mal interpréter certaines règles, surtout si elles sont ambiguës. Enfin, attention à la surcharge. Si votre fichier fait 500 lignes, la machine aura autant de mal à prioriser l'information qu'un humain face à une documentation indigeste.
Ces limites ne doivent pas vous décourager de documenter, bien au contraire. Elles prouvent qu'il faut le faire avec rigueur.
La mémoire technique n'est qu'une partie de l'équation. Une fois cette mémoire en place, qui s'assure qu'elle est utilisée correctement ?
Il y a une tendance de plus en plus forte qui consiste à utiliser une IA pour faire la revue de ce qu'une autre IA a produit. C'est un peu le serpent qui se mange la queue. En réalité, ça peut être très utile, à condition de ne pas s'arrêter là.
La revue par IA est excellente pour détecter les erreurs évidentes comme les fautes de style, les incohérences de nommage ou les bogues de surface. Ça décharge le réviseur humain des petits détails irritants et lui libère du temps pour se concentrer sur ce qui compte vraiment : la logique métier, les choix d'architecture, les cas limites et les tests automatisés. Utiliser un modèle différent de celui qui a généré le code peut même réduire les biais, chaque modèle ayant ses propres forces et angles morts.
Le piège, c'est de s’arrêter là. Même avec un accès complet à vos outils, à votre documentation ou à l'historique du projet, l'IA n'a aucun jugement. Elle possède l'information, mais ne comprend pas toujours quand elle est pertinente. Elle ne remettra jamais en question un choix d'architecture qui "fonctionne" techniquement mais qui ne convient pas du tout à votre contexte. Si aucun humain ne valide derrière, on se retrouve dans une boucle fermée dangereuse. Une IA génère un endpoint sans validation d'entrée, une autre l'approuve parce qu'aucune des deux ne connaît vos règles de validation métier.
“La revue par IA est un filtre, jamais un verdict. L'humain doit rester le dernier maillon de la chaîne.”
Cette rigueur doit s'étendre à toute l'équipe. Les fichiers de configuration IA ne devraient pas être l'affaire d'une seule personne dans son coin. Posez-vous ces questions : qui écrit les règles? Qui les maintient? Comment éviter que chaque membre de l'équipe ait ses propres conventions dans son fichier de configuration personnel, créant des incohérences dans le code généré?
La réponse est la même que pour n'importe quel autre artefact partagé. Traitez ces fichiers de configuration exactement comme du code source. Ils doivent être commités dans le dépôt, revus en équipe et maintenus collectivement. Quand quelqu'un ajoute une règle, l'équipe la valide. Quand une convention change, le fichier est mis à jour. Et surtout, la règle d'or doit être claire pour tout le monde : un humain valide absolument toute sortie de l'IA avant qu'elle n'aille en production.
Celui qui accepte une sortie d'IA sans la valider prend exactement le même risque qu'un développeur ou une développeuse qui merge du code sans le lire. L'excuse de la vitesse ne tient pas.
En fin de compte, vous restez l'unique responsable de ce que l'IA produit en votre nom. En cas de faille de sécurité, de bogues critiques ou de décisions mal avisées, l'outil ne portera aucune responsabilité légale ou morale. C'est vous qui répondez du code. C'est la meilleure raison d'investir dans cette rigueur au quotidien : guider la machine avec des fichiers de configuration solides, passer en revue tout ce qui est généré, et surtout, maintenir votre propre compréhension de ce qu'elle produit.
L'IA ne s'améliore pas toute seule. Mais avec un investissement minimal et cumulatif, quelques lignes dans un fichier de configuration, mises à jour au fil des corrections, chaque session devient meilleure que la précédente.
Ce n'est pas une question de résister à l'IA ou de l'adopter aveuglément. C'est une question de collaboration intelligente. J'ai appris, au fil de plusieurs mois d'utilisation quotidienne, que cette collaboration commence par comprendre comment l'outil fonctionne : il ne retient rien, il ne pense pas, il prédit. À vous de lui fournir le contexte qui transforme ses prédictions génériques en résultats adaptés à votre réalité.
Dès votre prochaine session avec l'IA, posez-vous une question : qu'est-ce que je viens de corriger, et comment je fais pour ne plus avoir à le corriger? La réponse à cette question, écrivez-la. C'est le début de la mémoire de votre IA.