Mon produit

GhostOne : des employés IA qui doivent prouver leur travail

Comment j'ai conçu de A à Z une équipe d'agents qui travaille dans les vrais outils d'une entreprise, sous contrôle humain.

Kamel DhakwaniCréateur · En ligne, bêta

Une caisse ne peut pas dire « c'est fait » si ce n'est pas fait. J'ai passé des années à concevoir des logiciels pour les points de vente, et cette évidence m'est restée. Quand les agents IA sont arrivés, j'ai vu l'inverse : des démonstrations impressionnantes, auxquelles personne n'aurait confié une vraie facture.

GhostOne est né de cet écart. Je l'ai créé de A à Z. Cette page explique comment il fonctionne, avec de vrais cas de figure que vous pouvez dérouler vous-même.

Le problème

Les projets d'IA en entreprise s'arrêtent presque toujours au même endroit. On obtient un assistant qui répond bien, et le travail continue de se faire à la main, dans les e-mails, les tableurs et les logiciels métier.

Le frein n'est pas l'intelligence du modèle. Ce sont les questions qu'une entreprise pose dès qu'une machine touche à ses systèmes. Qui a fait cela ? Avec quelle autorisation ? Est-ce vraiment arrivé ? Un agent incapable d'y répondre ne survit pas à son premier incident.

GhostOne donne donc à chaque entreprise une équipe d'agents avec un prénom et un métier, qui travaillent dans ses propres logiciels. L'application, WhatsApp, l'e-mail, la voix et l'API ne sont que des portes d'entrée. Derrière, il n'y a qu'un seul moteur, avec les mêmes droits et la même preuve.

La règle qui décide de tout

La valeur n'est pas dans le modèle. Les modèles progressent tous les quelques mois, et je les traite comme un moteur interchangeable. Ce qui dure, c'est le harnais autour : les droits, les validations, la mémoire, les process et la mesure.

Tout tient en une phrase : le code établit les faits et garde ce qu'il prouve, le modèle comprend la demande et choisit parmi ce qui lui est permis.

Le code sait qui parle, contrôle chaque appel et écrit le journal. Il ne devine jamais le sens d'un message à partir de mots-clés. Le modèle comprend une demande jamais vue, choisit l'outil et rédige la réponse. Il ne peut rien faire que le code ne lui permette pas.

Le mieux est de le voir. Dans le schéma ci-dessous, chaque colonne est un acteur, et le point lumineux suit la demande.

Cas de figure

Choisissez une demande et suivez-la

PersonneCodeModèlePorte

WhatsApp

Quel produit est le plus bas en stock cette semaine ?

Personne · 1/7

Une responsable achats écrit depuis WhatsApp, avec ses mots.

Exemples fictifs. Le chemin est celui que suit vraiment GhostOne.

Remarquez ce qui ne change jamais. Une question, un envoi ou un paiement passent par le même chemin. Seule la décision prise à la porte diffère.

Une seule porte pour chaque geste

Chaque appel d'outil passe la même porte, dans le même ordre, quel que soit le système branché derrière. Le calcul est unique, et il est le même pour tous les canaux. Essayez plusieurs combinaisons.

À vous de jouer

Passez un geste à la porte

Le geste

A le droit ?

Demandé clairement ?

  1. Droit
  2. Acte
  3. Accord
  4. Preuve
  5. Journal

En attente d'une personne

Une carte d'accord explique le geste. Rien ne part sans un « oui ». Ce qui est demandé clairement s'exécute. Ce qui ne l'est pas attend une validation.

Le système est fermé par défaut. Ce qui manque est refusé, une personne inconnue est restreinte. Un refus revient au modèle comme un résultat clair, avec ce qu'il peut faire à la place.

Dire n'est pas prouver

C'est le détail auquel je tiens le plus. Un modèle écrit volontiers « c'est fait », parce que c'est la suite probable de la phrase. Dans GhostOne, ce mot se mérite : c'est le résultat de l'outil qui décide de ce que l'agent peut affirmer.

Dire ou prouver

Le système répond. Que doit dire l'agent ?

Ce que le logiciel a répondu

Un agent sans preuve

C'est fait !

GhostOne

Peut-être créé, à vérifier.

Une réponse sans identifiant ne prouve rien. L'incertitude est dite.

La même règle vaut pour les fichiers. Un tableau produit sans aucune ligne s'affiche « Vide : 0 ligne », et l'agent explique pourquoi au lieu de le présenter comme prêt.

Ce que le modèle reçoit vraiment

Un agent ne « sait » que ce qu'on lui envoie à chaque aller-retour. L'ordre de cet envoi compte. Le début ne change pas d'un message à l'autre, ce qui permet au fournisseur de le relire depuis son cache, plus vite et moins cher.

Sous le capot

Ce qui part au modèle à chaque aller-retour

Touchez une couche pour l'ouvrir.

  1. Un socle d'environ 27 définitions complètes, selon les droits et ce qui est branché.

Stable, relu depuis le cacheChange à chaque message

Chaque morceau a sa raison, son moment et sa taille maximale. Le total est tenu par un test : on n'ajoute pas sans retirer.

J'ai aussi appris ce qu'il ne fallait pas faire. J'ai essayé quatre fois de cacher des outils à l'agent pour alléger cet envoi. Quatre fois, le résultat a été le même : un outil qu'on ne montre pas n'est jamais appelé. Le catalogue nomme désormais chaque outil permis, et l'agent choisit.

Brancher un logiciel sans écrire de code pour lui

Le code ne connaît que des actes : lire, créer, envoyer, payer, supprimer, régler. Il ne connaît ni client, ni logiciel, ni métier. Un logiciel branché demain suit donc la même porte, sans développement spécifique. Un test refuse tout nom de client dans le code commun.

Les branchements

Sept façons de brancher un logiciel, une seule porte

Serveurs MCP

Le logiciel présente ses outils. Chacun est classé par acte, et ce qui n'est pas sûr reste fermé.

Exemple « Où en est l'ouverture de ce magasin ? »

Lit, écrit avec accord

Un agent qui apprend, sous contrôle

L'agent retient où chacun range ses documents, ses préférences, ce qu'on lui a dit. Il le montre dans « Mémoire », et chaque ligne s'efface d'un geste. Ce qu'il apprend ne retire jamais une validation de l'entreprise.

Tout charger à chaque message le rendrait lent et cher. Il travaille donc comme une vraie assistante. Il a l'agenda du jour en tête, sort le dossier quand on parle de quelqu'un, et va aux archives quand on le lui demande.

Quand la même demande a réussi trois fois en un mois, l'agent propose de la faire tourner seule. La personne décrit alors le travail avec ses mots, l'agent écrit les étapes, les montre et les fait essayer à blanc.

Un programme à plusieurs étapes dans le studio GhostOne

Si le process envoie hors de l'entreprise, écrit dans un logiciel relié ou encaisse, une personne désignée doit l'activer. Chaque passage ouvre un dossier visible.

Les process d'une entreprise, affichés dans une conversation

Le produit se règle avec des mots simples. Le dirigeant ne voit ni serveur ni paramètre, mais des questions : votre équipe, ce qui part seul, comment on vous joint, ce que ça coûte.

Les réglages de GhostOne dans un réseau réel

L'épreuve du réel

GhostOne est déployé dans un réseau de franchise, sur ses vrais outils et avec ses vraies équipes. Autour de lui, j'ai connecté des applications de recrutement, de suivi de projets, de formation et d'audit.

Pour moi, « corrigé » doit se mériter. Un comportement ne compte comme acquis qu'après être passé plusieurs fois avec le vrai modèle, avoir tenu chez un second client d'un autre métier, et avoir été retesté en usage réel. Aucun mécanisme n'entre sans un cas qui le justifie.

Ce que j'en retiens

  • Une consigne reste une demande. Une limite qui compte doit vivre dans le code.
  • Le modèle change, le harnais reste. C'est là qu'il faut investir.
  • Un refus clair vaut mieux qu'une réussite inventée. La confiance se perd en une seule fausse confirmation.
  • Ce qui n'est pas mesuré n'est pas corrigé. Une impression de progrès ne suffit pas.

Une caisse évalue l'action, pas le caissier. GhostOne évalue l'action, pas le modèle.