Écosystème d’agents IA

Une démonstration d’IA impressionne cinq minutes ; un usage quotidien se juge sur des mois. Cet écosystème est ma manière de mettre l’IA appliquée à l’épreuve du travail réel — avec les contraintes que ça implique : ça doit tourner tous les jours, survivre à mes changements d’avis, et échouer proprement quand ça échoue.

Il ne s’agit pas d’automatiser pour automatiser, mais de déléguer ce qui est répétitif et vérifiable, en gardant la main sur ce qui engage.

Au centre, un agent résident tourne en permanence dans un conteneur sur un serveur. Je l’atteins indifféremment depuis Telegram, depuis le bureau ou en ligne de commande : un seul cerveau, plusieurs portes d’entrée, avec une mémoire qui persiste d’une session à l’autre.

Il tient l’agenda et les rappels, surveille les sujets que je suis, rédige, et prépare mes points de la journée. Ce qu’il ne fait pas, volontairement : écrire du code. Cette tâche revient à des agents de code invités, ouverts à la demande sur un projet précis.

Coordonner plusieurs agents sur un même dépôt pose un problème très concret : comment savoir qui fait quoi, et éviter que deux d’entre eux se marchent dessus. La réponse ici n’est pas un protocole exotique mais les issues GitHub, utilisées comme canal de traçabilité — avec des labels, des signatures et des verrous explicites.

Chaque intervention laisse une trace lisible par un humain comme par un agent. C’est ce qui rend l’ensemble diagnosticable : quand un comportement surprend, l’historique existe.

Le socle du système, ce sont des skills : des procédures réutilisables, versionnées dans un dépôt, relues et corrigées quand elles produisent de mauvais résultats. Chacune documente ses pièges et ses vérifications, parce qu’une instruction qui ne dit pas comment elle peut échouer finit par échouer en silence.

Un contrôle quotidien vérifie que ce qui est déployé correspond bien à la source, et des tests de régression signalent les dérives. C’est du travail d’ingénierie logicielle ordinaire, appliqué à des instructions plutôt qu’à des fonctions.

Un brief chaque matin rassemble agenda, veille et sujets en attente. Un récapitulatif hebdomadaire est généré, mis en forme, déposé sur mon Drive et annoncé par notification. Une veille surveille pages et flux, et ne m’alerte qu’en cas de changement réel. Des rappels ponctuels se déclenchent au bon moment. La transcription vocale, elle, s’exécute localement : le son ne quitte pas le serveur.

Un détail qui compte : quand une tâche n’a pas besoin d’un modèle de langage, elle n’en utilise pas. Une tâche planifiée simple est plus rapide, moins chère et plus fiable qu’un agent. Savoir quand ne pas mettre d’IA fait partie du métier.

Le principe directeur est de garder le contrôle humain : les agents produisent et proposent, je décide. Les garde-fous ne sont pas implicites, ils sont écrits — critères d’évaluation dans les skills, contrôles de synchronisation, tests de régression, règles de confidentialité contraignantes.

Ces règles couvrent notamment les éléments sensibles d’infrastructure et les données privées, qui restent hors des espaces partagés et de tout contenu public. S’y ajoute une exigence d’honnêteté que j’applique à mes propres notes : une mesure porte sa date et sa machine, et « vérifiable » ne veut pas dire « vérifié ».

L’ensemble s’appuie sur des serveurs que j’administre moi-même — celui de l’agent, mais aussi ceux qui hébergent mes applications et des sites clients : sécurisation des accès, configuration, déploiement. J’y fais tourner plusieurs outils auto-hébergés en conteneurs, dont une interface de chat et un moteur d’automatisation.

Je teste aussi régulièrement des modèles de langage locaux et je les compare sur un critère précis : leur capacité à utiliser des outils correctement. C’est là que les écarts entre modèles se voient le mieux, bien plus que sur la qualité de rédaction.

Il faut le dire clairement : c’est un écosystème personnel, pas une infrastructure d’entreprise. Son intérêt n’est pas son échelle, mais le fait qu’il tourne pour de vrai, tous les jours, avec quelqu’un qui en subit les défauts — moi.

C’est ce qui en fait un terrain d’expérimentation honnête. Les pratiques qui tiennent ici — expliciter les garde-fous, tracer les décisions, documenter les modes d’échec, ne pas mettre d’IA là où elle n’apporte rien — sont celles que je propose ensuite sur des projets professionnels. On les retrouve dans ma manière d’aborder Palabre comme le SaaS immobilier.