Notre démarche reprend les pratiques de modernisation applicative de Pivotal Labs et les applique à un nouveau type de logiciel : un logiciel qui décide. Le test ne vérifie plus seulement un résultat ; il fixe le périmètre d'action de l'agent.
Chez Pivotal Labs, moderniser une application voulait dire comprendre le domaine avant de toucher au code : Event Storming pour révéler le process, découpage en tranches livrables, pair programming et TDD pour avancer sans régression.
Ces pratiques répondent exactement au risque principal des agents : le désalignement. Un agent qui comprend mal une règle métier, ou qui dispose de plus de droits que nécessaire, finit tôt ou tard par agir hors de son rôle.
En spécifiant chaque comportement par un test, puis en observant l'agent avant de lui ouvrir le moindre accès, on rend ce risque visible et mesurable dès la conception.
Vos règles de gestion sont déjà dans vos applicatifs. On les extrait plutôt que de les réinventer.
Aucun comportement n'est développé sans scénario écrit : attendu, interdit, escalade.
Les droits se déduisent de ce que l'agent fait réellement en sandbox, pas de ce qu'on imagine.
Nos ingénieurs travaillent avec les vôtres. À la fin, l'agent et sa méthode vous appartiennent.
En atelier avec les métiers, nous faisons émerger les événements, commandes, décisions et acteurs du process. Les points de friction et les décisions répétitives deviennent les candidats naturels à l'automatisation.
Nous analysons le code source des applications qui portent le process : ERP spécifique, application maison, scripts, macros. Nous en extrayons les règles de gestion, les invariants et les cas limites, puis les validons avec les métiers.
À la manière d'un découpage en services, nous fixons les frontières de responsabilité : quelles tâches confier à des agents mono-tâche, lesquelles orchestrer par un coordinateur, où garder l'humain dans la boucle.
Comme en TDD, chaque comportement commence par un scénario qui échoue : ce que l'agent doit faire, ce qu'il ne doit jamais faire, quand il doit s'arrêter et demander. Le développement consiste à faire passer ces scénarios, en binôme avec vos équipes.
L'agent est exécuté en environnement isolé, sur des cas réels et adverses. Chaque outil appelé, chaque donnée lue, chaque tentative d'action est tracée. Le cadre d'autorisations est déduit de cette observation : tout ce qui n'a pas été observé et validé reste refusé.
L'agent part en production avec son cadre et sa suite de tests, rejouée à chaque évolution du modèle, du prompt ou des outils. Son comportement réel reste comparé à celui validé en sandbox. Vos équipes sont formées pour le faire évoluer.
Hébergement souverain, aucune réutilisation de vos données pour entraîner des modèles tiers, traitements cadrés avec vous.
Chaque exécution laisse une trace : intention, outils utilisés, données consultées, décision prise.
Un agent peut être suspendu, restreint ou révoqué à tout moment, sans impact sur vos applicatifs.
C'est un agent qui agit en dehors de ce que vous attendez de lui : il applique mal une règle, prend une décision qui revenait à un humain, ou utilise un accès qu'il n'aurait pas dû avoir. Nos tests et l'observation en sandbox servent à le détecter avant la production.
Parce que c'est souvent le seul endroit où vos règles de gestion sont écrites de façon complète et exacte. Les extraire évite à l'agent de « deviner » vos règles, et fournit directement les scénarios de test.
Le process décide. Une tâche bien délimitée appelle un agent mono-tâche, plus simple à tester et à auditer. Un process qui traverse plusieurs services appelle un coordinateur qui enchaîne des agents mono-tâche, chacun gardant son propre cadre.
Notre approche est agnostique du fournisseur : Claude, ChatGPT, Mistral hébergé en France, ou un modèle open source hébergé en local. Les scénarios de test et le cadre d'autorisations restent identiques ; changer de modèle revient à rejouer la suite en sandbox.
Quelques jours : de 2 à 6 jours pour un agent mono-tâche, de 8 à 15 pour un coordinateur, observation en sandbox comprise. Le délai exact dépend de la complexité du process et est confirmé à l'issue de la Discovery.
Son cadre s'applique à l'exécution : une action non autorisée est bloquée et signalée. L'écart est ajouté à la suite de tests, corrigé, puis validé de nouveau en sandbox avant d'être redéployé.
Un échange de 30 minutes, sans engagement, pour identifier une première tranche à confier à un agent.