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 avec une IA principale qui connaît mes projets, et avec des agents spécialisés qu'elle peut lancer quand une tâche le demande.
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 qui peut l'être.
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. 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. J'ai donc pris l'habitude de mettre à jour mes notes à la fin de chaque session de travail, 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.
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. Je le lance systématiquement 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.
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 toujours. Un rapport d'agent est un point de départ, pas une vérité. Je vérifie les conclusions importantes avant d'agir.
- 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. 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é à lui donner ce dont un collègue aurait besoin : du contexte, des méthodes et des tâches clairement définies.
