Le 12 octobre, mon Mac a saturé. Plusieurs agents de code travaillaient en même temps sur Krizaka, chacun avec ses builds, ses conteneurs et son simulateur, et le système a fini par refuser d'ouvrir un fichier de plus. Je raconte la panne dans le billet sur le Mac. Ce jour-là, j'ai compris une chose simple : laisser des agents écrire du code, ce n'est pas de la magie. C'est de l'organisation.
Deux mots reviennent partout en ce moment : « agentique » et « agnostique ». Je les reprends ici, simplement, avec ce que nous avons vraiment construit, et ce qui est encore en cours.
Ce qui rend un système agentique
Un modèle seul répond à une question. Un système devient agentique quand on lui donne cinq choses.
Un objectif, plutôt qu'une question : « résume les nouveaux PDF de ce dossier chaque matin ». Des outils, pour agir sur le monde : lire un fichier, interroger une base, appeler une API (j'explique les outils et MCP dans les bases). De la mémoire, pour savoir où il en est. Une boucle : planifier, agir, regarder le résultat, recommencer. Et une approbation humaine avant tout ce qui a un effet réel.
C'est la cinquième qui fait la différence entre un agent et un stagiaire laissé seul avec les clés.
Agnostique : ce que ça rapporte, ce que ça coûte
« Agnostique », ici, veut dire que le système ne dépend pas d'un modèle ou d'un fournisseur en particulier. Dans Orazaka, le moteur que je construis, le modèle utilisé est une ligne en base : une table relie chaque nom de modèle à son fournisseur, et un routeur lit ces lignes à chaque appel (ADR-030). Un modèle local sur Ollama et un modèle hébergé passent par la même API.
Ce que ça rapporte, c'est concret. Pas d'enfermement chez un fournisseur. Le droit de choisir le moins cher qui suffit, tâche par tâche. Et la souveraineté : le même travail peut tourner sur une machine que vous contrôlez.
Ce que ça coûte, on le dit moins. On vise le plus petit dénominateur commun : une fonction propre à un fournisseur ne sert à rien si les autres ne l'ont pas. Il faut évaluer chaque modèle sur ses propres tâches, parce qu'un nom de modèle ne garantit pas une qualité. Et il y a des pièges, comme cette étape qui partait en silence vers un autre modèle que celui demandé. Depuis, un modèle dont le fournisseur ne répond pas échoue en le disant.
Des workflows dont les étapes sont des données
Un agent libre décide lui-même de ses étapes. Pour les clients, j'ai fait un choix plus prudent. Un Studio, dans Orazaka, est un workflow : un graphe d'étapes versionné (appels de modèles, transformations, approbations humaines, connecteurs), décrit comme des données. Un pack est un dossier qui livre des Studios ; l'installer écrit des lignes en base et ne change pas une ligne de code (la documentation des packs).
La transformation du prompt fait partie de ces étapes. Ce que la personne tape est enveloppé dans une direction structurée avant d'arriver au modèle : le sujet d'abord, puis la lumière, l'objectif, la palette, et les exclusions déplacées dans le texte quand le modèle ne lit pas de prompt négatif. J'ai mesuré ce que ça change dans l'anatomie d'un prompt.
Et avant toute étape, la politique de contenu fait office de garde-fou : la demande est classée localement, et ce que l'opérateur refuse ne part nulle part. J'en parle dans le billet sur les modèles qui refusent.
Les agents locaux : en cours
Le vrai agent, celui qui travaille sur votre machine pendant que vous dormez, est en cours. L'architecture est écrite dans une décision qui n'est pas encore fusionnée (ADR-079), et la première tranche, un résumé des nouveaux PDF chaque matin sur le Mac, est en revue.
Ce qu'elle prévoit, je le trouve plus intéressant que n'importe quelle démo. Chaque outil déclare son effet : lecture, écriture, externe, exécution, et un effet inconnu est traité comme une exécution. Rien n'écrit ni ne sort sans approbation. Un « toujours autoriser » devient une permission étroite, enregistrée. Il y a des budgets par exécution et par jour, un bouton d'arrêt, un journal d'audit où chaque entrée est chaînée à la précédente, et pas de shell dans la première version. Dans la première tranche, le plan est fixe : le modèle ne choisit même pas ses outils. Et tout doit pouvoir tourner hors ligne.
Je l'écris au futur parce que ce n'est pas livré. Je reviendrai quand ça tourne.
Comment je suis sorti du vibe coding
Le vibe coding, c'est demander à une IA d'écrire du code, regarder si ça a l'air de marcher, et continuer. Au début, c'est grisant. Puis le Mac sature, une session casse ce qu'une autre a fait, et on ne sait plus qui a changé quoi.
Krizaka est en grande partie écrit par des sessions d'agents que je dirige, souvent plusieurs en parallèle. Ce qui a changé, ce ne sont pas les agents, ce sont les garde-fous autour.
Un fichier de règles que chaque session lit avant de commencer : un test qui échoue d'abord, puis le correctif ; jamais de fusion tant qu'une vérification est rouge ou en attente ; une petite pull request par étape. Un verrou pour les tâches lourdes, ajouté le 12 octobre. Une CI qui refuse ce qui ne passe pas. Et des règles écrites après chaque erreur : une fusion faite trop tôt, avant la fin d'une analyse de sécurité, a donné la règle « jamais de fusion avec un check en attente » ; une session qui a affiché un secret dans sa sortie a donné un garde automatique qui refuse toute commande capable de le faire.
Ce que j'en retiens : un agent ne devient pas fiable parce qu'il est intelligent. Il devient fiable parce qu'on lui donne un objectif clair, des outils limités, des tests qui disent non, et une personne qui approuve ce qui compte.
Ce que vous pouvez en retenir
Si on vous vend un système « agentique », demandez-lui ses cinq pièces : l'objectif, les outils, la mémoire, la boucle, et surtout l'approbation humaine. Si on vous vend un système « agnostique », demandez comment il évalue les modèles qu'il vous propose. Et si vous laissez des agents écrire votre code, écrivez d'abord les règles qu'ils devront suivre, puis les tests qui les feront échouer.
