Quand on parle d'IA au travail, on imagine souvent une fenêtre de discussion où l'on pose une question avant de copier la réponse. C'est comme ça que j'ai commencé, et j'ai vite atteint les limites de cet usage : à chaque nouvelle conversation, il fallait tout réexpliquer. Le projet, les choix techniques, les conventions, ce qui avait déjà été tenté. J'ai donc changé d'approche. Aujourd'hui, je travaille tous les jours avec Claude Code, directement dans le terminal, sur une soixantaine de projets. Je traite l'IA comme un collègue : elle s'occupe de faire le travail, mais c'est moi qui décide et qui valide.
Une IA principale comme point d'entrée unique
Plutôt que de jongler entre plusieurs outils, je passe presque toujours par la même IA. C'est mon interlocutrice principale : je lui décris ce que je veux faire, elle analyse la demande, propose une approche et exécute ce que je lui confie.
L'intérêt n'est pas l'IA elle-même, mais la continuité. Comme elle dispose toujours du même socle d'informations, ses réponses sont cohérentes d'un jour à l'autre. Elle reprend mes conventions de nommage, respecte l'architecture en place et évite de me proposer des solutions que j'ai déjà écartées.
Le contexte : mes notes et la documentation des projets
Une IA sans contexte donne des réponses génériques. Avec du contexte, elle devient réellement utile. Avec une soixantaine de projets, c'est la partie de mon organisation à laquelle je consacre le plus de soin.
Ce que je lui fournis
- La documentation de chaque projet : objectif, architecture, technologies utilisées, commandes pour installer et lancer le projet.
- Mes notes de travail : décisions prises et leurs raisons, problèmes rencontrés, pistes abandonnées.
- Les conventions : style de code, structure des dossiers, façon de rédiger les commits ou la documentation.
- L'état d'avancement : ce qui est terminé, ce qui est en cours, ce qui reste à faire.
Les notes sur les décisions sont sans doute les plus précieuses. Savoir pourquoi une solution a été choisie évite à l'IA, comme à moi, de revenir sans cesse sur les mêmes débats.
Une documentation qui doit rester vivante
Ce système ne fonctionne que si le contexte est à jour. Une documentation obsolète est pire que pas de documentation du tout : l'IA s'y fie et produit des réponses fausses avec assurance. Pour moi, la doc suit le code : tant qu'elle n'est pas à jour, la tâche n'est pas finie. À la fin de chaque session, je m'assure que tout est à jour, souvent en demandant à l'IA de résumer ce qui a changé. C'est d'ailleurs ce besoin qui m'a amené à créer mon premier agent.
Comment je formule mes demandes
Je n'écris pas de prompts savants. J'écris comme je parle, comme je le ferais avec un collègue assis à côté de moi.
- Des captures d'écran. J'en envoie beaucoup, avec une petite remarque. Je vois souvent ce qui cloche avant de savoir quoi changer, et une image dit les choses plus vite qu'une longue description.
- Les logs bruts. Quand j'ai une erreur, je colle le log tel quel plutôt que de le résumer.
- Des questions à choix quand je ne sais pas. Quand je ne sais pas encore ce que je veux, je le dis. Je demande alors à l'IA de me poser des questions à choix pour m'aider à trouver.
Ma façon d'avancer
Je commence presque toujours par comprendre avant de toucher au code. Ma demande de départ ressemble souvent à : « analyse et propose, ne change rien encore ».
Ensuite, je demande des options, idéalement avec une recommandation. L'IA fait le tour des possibilités, mais c'est moi qui tranche. Pour le design, je demande plusieurs versions, je choisis celle que j'aime et on raffine à partir de là.
Je teste toujours moi-même. Un build qui passe, ça ne prouve pas que ça marche. Et à la fin, je vérifie que tout est à jour : code, documentation, notes.
Mes règles, écrites une fois pour toutes
Avec le temps, j'ai mis mes règles par écrit pour ne pas avoir à les répéter à chaque session :
- Pas de commit ni de push sans que je le demande.
- Rien en mémoire sans mon accord.
- Si l'IA voit une meilleure façon de faire, elle me le dit avant d'agir.
- La doc suit le code, sinon la tâche n'est pas finie.
- Les releases et les versions, c'est moi qui m'en occupe.
Quand l'IA n'est pas d'accord avec une de ces règles, on en discute. Mais c'est moi qui ai le dernier mot.
Des modèles d'agents pour les tâches précises
Certaines tâches reviennent souvent, demandent une méthode rigoureuse et n'ont pas besoin de tout le contexte de la conversation. Pour celles-là, j'ai rédigé des modèles d'agents. Un modèle, c'est une sorte de fiche de poste : il décrit le rôle de l'agent, les étapes à suivre, ce qu'il doit vérifier et le format de son rapport. Mon IA principale peut lancer ces agents quand elle juge que c'est pertinent, ou quand je le lui demande.
L'agent de vérification de la documentation
Son rôle est simple : comparer la documentation avec l'état réel du projet. Il vérifie notamment que :
- les commandes indiquées fonctionnent toujours ;
- les fichiers et dossiers mentionnés existent encore ;
- les fonctionnalités décrites correspondent au code ;
- les nouveautés récentes sont bien documentées.
À la fin, il me rend une liste des écarts trouvés, classés par importance. Je décide ensuite de ce qu'il faut corriger. Ce contrôle régulier garantit que le contexte dont dispose mon IA principale reste fiable.
L'agent de test complet
Le second agent que j'utilise le plus sait tester un projet de bout en bout. Il connaît la procédure : installer les dépendances, lancer la suite de tests, démarrer l'application, vérifier les parcours principaux et relever les erreurs. Au lieu d'enchaîner ces étapes moi-même ou de les réexpliquer à chaque fois, je délègue.
Il me renvoie un rapport clair : ce qui passe, ce qui échoue, les messages d'erreur et, quand c'est possible, une piste sur l'origine du problème. Ce rapport ne remplace pas mon propre test : il dégrossit le travail, puis je vérifie moi-même avant de considérer une fonctionnalité comme terminée.
Comment j'écris un modèle d'agent
Avec l'expérience, mes modèles suivent tous à peu près la même structure :
- Le rôle : une ou deux phrases sur ce que fait l'agent et ce qu'il ne fait pas.
- Les entrées : de quelles informations il a besoin pour travailler.
- La méthode : les étapes à suivre, dans l'ordre.
- Les critères : ce qui compte comme une réussite ou un problème.
- Le format de sortie : la forme exacte du rapport attendu.
Plus le modèle est précis, plus les résultats sont réguliers. Un agent à qui l'on dit seulement « vérifie la doc » fera un travail approximatif. Un agent qui sait exactement quoi contrôler et comment le présenter devient un outil fiable.
Exigeant sur les détails, attaché à la simplicité
Je suis exigeant sur les détails visuels : un espacement inégal, un logo pas centré, une flèche collée sur le texte. Ce sont souvent ces petites remarques, captures à l'appui, qui occupent la fin d'une session.
Par contre, je veux que ça reste simple. Si une solution devient trop compliquée pour ce qu'elle apporte, je recule sans problème. L'IA propose volontiers des constructions élaborées ; mon rôle est de juger si elles en valent la peine.
Ce que ça change concrètement
Le gain le plus visible, c'est le temps : je n'explique plus mes projets en boucle, et les tâches répétitives sont déléguées. Mais le bénéfice le plus important est ailleurs. Mon IA principale reste concentrée sur la conversation et la réflexion, pendant que les agents traitent des tâches bien délimitées sans encombrer cet échange. Je garde une vue d'ensemble claire, et chaque tâche est faite avec une méthode constante.
Il y a aussi un effet inattendu : cette organisation m'a obligé à mieux documenter mes projets. Ce qui sert à l'IA sert aussi à moi, et à toute personne qui reprendrait le projet un jour.
Les limites à garder en tête
- Je relis et je teste toujours. Un rapport d'agent ou un build qui passe est un point de départ, pas une preuve. Je vérifie moi-même avant d'agir ou de valider.
- Le contexte a un coût. Trop d'informations noie l'essentiel. Je préfère des notes courtes et structurées à des documents interminables.
- Les données sensibles restent à part. Je ne mets pas de mots de passe, de clés d'accès ou d'informations confidentielles dans le contexte fourni à l'IA.
- Les modèles d'agents vieillissent. Quand un projet évolue, je relis mes modèles pour qu'ils restent adaptés.
Par où commencer
Si vous voulez essayer une organisation similaire, inutile de tout mettre en place d'un coup. Commencez par rédiger une fiche de contexte pour un seul projet : son objectif, sa structure et la façon de le lancer. Donnez-la à votre IA au début de chaque session et observez la différence. Notez aussi les règles que vous vous surprenez à répéter : une fois écrites, vous n'aurez plus à les redire. Ensuite, repérez une tâche que vous répétez souvent et écrivez votre premier modèle d'agent pour elle. C'est en l'utilisant que vous verrez ce qu'il faut préciser.
Pour moi, l'IA est devenue utile le jour où j'ai arrêté de la traiter comme un moteur de recherche amélioré et où j'ai commencé à la traiter comme un collègue : je lui donne du contexte, des méthodes et des règles claires, elle fait le travail, et c'est moi qui décide.
