Un agent est un employé à risque.

Une entreprise ne manque pas d’outils d’IA. Elle manque d’un endroit où l’on sait qui a fait quoi, avec quels outils, et qui a validé. C’est ce que NakamaOS est pour nous, et c’est pour ça que nous l’avons d’abord fait tourner chez nous.

Nakama est une entreprise entièrement gérée par des agents IA : les rôles d’agent et les agents de code font le travail, un opérateur humain valide ce qui part. Ce n’est pas une démonstration : il faut répondre, tenir un produit en production et publier chaque mois un rapport avec ses sources. Chaque scénario tourne chez nous avant d’être proposé à qui que ce soit.

1. 1

   Il fait le travail ; une personne valide.

   L’agent trie, prépare, écrit, propose. Ce qui part, s’envoie, se publie ou se fusionne attend une validation.

2. 2

   Ce qu’il ne doit pas faire est bloqué par le code, pas seulement demandé.

   Une consigne n’est pas un contrôle : le modèle lit l’instruction et la donnée dans le même canal. Ce qui compte est appliqué par le moteur, en dehors du modèle.

3. 3

   Ce qui est garanti, bloqué ou seulement demandé s’écrit dans trois colonnes.

   Pour chaque écran de NakamaOS : ce que l’agent fait, ce que le logiciel impose, ce qui est validé. Jamais une promesse sans sa colonne.

4. 4

   Chaque mois, quelqu’un vérifie.

   La version, les tests rejoués, la configuration, le diff des consignes et des missions. Le bulletin du mois reste à vous.

5. 5

   Un chiffre sans sa source ne se publie pas.

   Un export, une capture, un registre. Sinon, la phrase n’existe pas.

• Des employés à risque

  Une entreprise peut tourner avec des agents, à condition de les traiter comme des employés à risque : accès minimum, revue, journal. Un agent qui a tous les droits est un incident en attente.

• L’audit avant le sur-mesure

  L’équipe de base s’installe sans audit ; un agent construit pour vous, jamais : on regarde votre métier d’abord, sinon on automatise le désordre. La moitié de la valeur de l’audit : dire ce qu’il ne faut pas automatiser.

• Votre modèle, votre clé

  Le fournisseur du modèle est le vôtre, sous votre contrat, avec votre clé et son plafond. Nous ne sommes liés à aucun fournisseur. Une formule tout compris, tokens inclus, existe sur demande.

• La preuve remplace la présence

  Ce qui n’est pas mesuré n’a pas été fait, pour les développeurs comme pour les agents : chaque chiffre publié l’est avec sa source.

• Réglé, puis vérifié

  La version installée chez vous est réglée par un spécialiste de la sécurité applicative pour que les agents ne fassent que ce que vous autorisez, puis vérifiée chaque mois : la version, les tests rejoués, la configuration, le diff des consignes et des missions.

Agent

Un programme qui agit : il lit, il appelle des outils, il écrit. Il a des accès et il se trompe. On le traite comme un employé à risque, pas comme une fonctionnalité.

Persona

Un agent taillé pour une fonction : son rôle, sa voix, sa fiche de poste. Techniquement, une consigne posée en tête de chaque message ; les personas partagent le même moteur et les mêmes outils, et les permissions se donnent outil par outil. Un persona par fonction ; jamais un agent universel.

Mission

Une tâche programmée : elle se lance seule, à heure fixe ou sur un événement, avec un jeu d’outils réduit et un délai. Une mission prépare ; ce qui est irréversible, envoyer ou publier, sa consigne le laisse à une personne, et elle ne peut obtenir aucune permission.

Scénario

Un déclencheur, les agents qui font, ce qui sort, la validation. C’est ainsi que nous décrivons ce que nous automatisons, chez nous comme chez vous.

Journée type

Un scénario écrit d’après ce que font les agents dans NakamaOS, sur l’accueil. Jamais un relevé du jour : aucun registre réel n’est publié.

Registre

Ce qu’un agent a fait, quand, avec quel outil, sur quelles données. Consultable, copiable tel quel. C’est la source des chiffres que nous publions — le blog, lui, est la publication.

Revue

Ce qu’un agent produit est validé avant d’entrer en production : une pull request, une réponse client, un document. Ce qui s’envoie ou se publie, le moteur l’impose ; pour une pull request, c’est une règle écrite dans le dépôt.

Niveau confidentiel

Un message classé confidentiel envoie les appels secondaires — le classement, le travail délégué à un second modèle — sur un modèle local ; la conversation principale reste sur le modèle choisi. Le niveau confidentiel ne concerne que ces appels secondaires, et le registre le montre.

Validation

Le geste humain sur ce qui part : envoyer, publier, payer, fusionner. L’agent prépare ; validé avant de partir. Une personne peut autoriser un outil « toujours » ; un agent ne peut pas se l’accorder.

Chapitre

Le récit d’une fonction confiée aux agents, en trois articles du blog : l’état avant, le jour où elle passe aux agents, le bilan ensuite.

Diff

Les lignes de code qu’un changement ajoute et retire. C’est ce qu’un relecteur lit avant d’accepter le changement.

Pull request

La demande d’intégrer un changement de code. Les agents de code l’ouvrent avec son rapport ; validée avant fusion. La règle est écrite dans le dépôt, pas imposée par le moteur.