Cette semaine, je n'ai pas essayé d'ajouter plus d'agents.
J'ai plutôt travaillé sur la surface qui leur permet d'être utiles.
C'est une distinction importante. On parle beaucoup de modèles, de context windows, de prompts, de connecteurs, de MCP, de navigateurs automatisés et de workflows multi-agents. Tout ça compte. Mais dans la pratique, le problème arrive souvent avant : l'agent ne sait pas dans quel monde il travaille.
Il ne sait pas quel projet est prioritaire.
Il ne sait pas ce qui est une idée, ce qui est une décision, ce qui est bloqué, ce qui a été vérifié.
Il ne sait pas si le repo ouvert est le vrai repo.
Il ne sait pas si la documentation est encore vraie.
Il ne sait pas si son prochain geste doit être d'écrire du code, de tester, de publier, d'attendre une décision humaine, ou de ne rien toucher.
Un agent sans cockpit donne une impression de puissance, mais il travaille dans le brouillard.
Le vrai produit n'est pas toujours l'application
Quand on construit plusieurs choses en parallèle, on finit par croire que le chaos vient du nombre de projets.
Je pense de moins en moins que ce soit vrai.
Le chaos vient surtout de l'absence de surface commune. Pas une grosse plateforme compliquée. Pas un CRM de plus. Pas un tableau magique qui promet de tout organiser. Une surface simple où l'on peut voir, chaque matin :
- ce qui compte aujourd'hui ;
- ce qui est actif ;
- ce qui est bloqué ;
- ce qui a été prouvé ;
- ce qui doit être décidé ;
- ce qu'un agent peut prendre sans inventer le contexte.
Autrement dit : un cockpit.
Pas un dashboard décoratif. Un cockpit de travail. Un endroit où l'information sert à agir.
Les agents amplifient l'état de votre système
Un agent IA n'arrive pas dans une organisation comme une personne calme qui remet tout en ordre par magie.
Il amplifie ce qui existe déjà.
Si les priorités sont floues, il produit plus vite des choses floues.
Si les sources de vérité sont dispersées, il réconcilie mal les contradictions.
Si les décisions vivent dans la tête de quelqu'un, il les redemande ou les suppose.
Si les preuves ne sont pas conservées, il répète les mêmes vérifications.
Si le système confond « idée intéressante » et « travail à faire maintenant », il part trop facilement dans les branches.
C'est pour ça que je me méfie des démonstrations d'agents qui commencent directement par l'exécution.
L'exécution est la partie spectaculaire. Mais la vraie question est plus simple : l'agent sait-il où poser les yeux ?
Trois surfaces avant l'automatisation
Avant de brancher plus d'automatisation, je veux trois surfaces lisibles.
La première est la surface de commande : qu'est-ce qui compte maintenant ?
Elle doit être courte. Si tout est prioritaire, l'agent n'a aucune chance. Il va optimiser localement : corriger un détail, nettoyer un fichier, écrire une section, lancer un test. Ce sont parfois de bons gestes. Mais ils peuvent être inutiles si le vrai blocage est une décision produit, une validation de domaine, une dépendance humaine ou une contrainte de publication.
La deuxième est la surface de preuve : qu'est-ce qui a été vérifié ?
Un bon système de travail ne dit pas seulement « c'est prêt ». Il garde la trace de ce qui a été lancé, ce qui a passé, ce qui a échoué, et pourquoi l'échec ne bloque pas forcément. Cette couche est essentielle avec les agents, parce qu'ils sont très bons pour continuer à produire même quand la base factuelle est faible.
La troisième est la surface de décision : qu'est-ce qui ne doit pas être réinventé ?
Les agents ont besoin de connaître les choix durables. Pas toute l'histoire. Juste les garde-fous : quels outils on évite, quelle posture on garde, quels compromis sont déjà tranchés, quels sujets demandent une validation humaine.
Sans ces trois surfaces, l'automatisation ajoute de la vitesse à un système qui n'a pas encore de direction.
Ce que je veux donner à un agent le matin
Je veux pouvoir ouvrir une session et lui donner une mission concrète :
Voici le contexte.
Voici le projet.
Voici la source de vérité.
Voici ce qui est interdit.
Voici ce qui est bloqué.
Voici la définition de terminé.
Voici les preuves attendues.
Ce n'est pas du micromanagement. C'est de l'ergonomie.
Un bon agent ne devrait pas avoir à deviner si le but est de faire un plan, de produire une version publiable, de vérifier un déploiement, de corriger une interface, ou de s'arrêter parce qu'une clé manque. Le système doit rendre ces choses explicites.
Plus je travaille avec des agents, plus je crois que la compétence importante n'est pas seulement « bien prompter ». C'est savoir construire un environnement où le prompt n'a pas à porter toute l'organisation sur son dos.
Le cockpit est une forme de souveraineté
Il y a un lien direct avec la souveraineté technique.
Posséder son infrastructure ne veut pas seulement dire contrôler des serveurs. Posséder son travail veut dire savoir où sont les décisions, les preuves, les actifs, les risques et les prochaines actions.
Quand tout est dans des conversations, des onglets, des souvenirs et des intentions, on ne possède pas vraiment le système. On le ressent. On le porte mentalement.
Un cockpit transforme cette charge mentale en surface partageable.
Et dès que la surface existe, les agents deviennent beaucoup plus intéressants. Ils peuvent inspecter, comparer, vérifier, rédiger, tester, résumer, préparer. Ils peuvent reprendre une mission sans repartir de zéro. Ils peuvent laisser des preuves au lieu de simples impressions.
Le gain n'est pas seulement la vitesse. C'est la continuité.
Une petite équipe a besoin de moins de magie
Pour une petite équipe, le piège est de chercher l'outil total trop tôt.
Je préfère commencer plus simplement : quelques documents vivants, une carte des projets, un journal des preuves, une liste claire des décisions, une file d'attente de missions. C'est moins impressionnant qu'une plateforme agentique complète. Mais c'est beaucoup plus facile à corriger.
Quand cette couche devient utile manuellement, elle peut ensuite devenir un produit.
Pas l'inverse.
Le produit logiciel devrait naître d'un workflow qui marche déjà, pas d'une fiction d'interface.
La question de demain matin
La bonne question pour travailler avec des agents n'est donc pas : « Quel agent dois-je ajouter ? »
C'est plutôt :
Est-ce que mon système de travail est assez clair pour qu'un agent puisse aider sans inventer ?
Si la réponse est non, le prochain levier n'est peut-être pas un nouveau modèle. C'est une meilleure surface de commande. Une meilleure trace des preuves. Une meilleure distinction entre idée, décision, blocage et action.
Les agents IA n'ont pas seulement besoin de contexte.
Ils ont besoin d'un cockpit.
Je partage les prochaines notes de chantier par courriel : produits IA, agents, souveraineté technique, PME québécoises et construction sobre. Si ce type de retour terrain t'intéresse, inscris-toi au journal.