Un agent IA qui tourne, tout le monde peut en montrer un. Une démo impressionnante se monte en une journée. Ce qui est devenu rare — et c'est le vrai sujet — c'est de pouvoir répondre par écrit à la question : qu'est-ce qui prouve que ce système fait ce qui a été promis ?
Chez OpenUp, la réponse tient en quatre pièces. On les écrit avant, pendant et après le code. Ensemble, elles forment ce qu'on appelle la chaîne opposable — parce que chaque promesse du chantier renvoie à un document qu'on peut poser sur la table.
1. La spécification — le périmètre écrit
Avant la première ligne de code, un document dit ce que le système fait, ce qu'il ne fait pas, et qui arbitre.
Sur un chantier d'agents, ce dernier point n'est pas un détail : pour chaque action engageante — envoyer, payer, notifier, valider un dossier — la spécification nomme le rôle humain qui tranche. L'agent propose sur pièces ; un humain arbitre ; l'arbitrage est tracé. Un système dont on ne peut pas dire qui a validé quoi n'est pas un système en production, c'est un prototype qui a échappé à son auteur.
La spécification borne aussi le périmètre. Ce qui n'y est pas n'est pas dû — et ce qui y est se recette, point par point, à la livraison.
2. L'architecture écrite — sur quoi ça se branche, où vivent les données
Le deuxième document répond à trois questions qu'un DSI, un RAF ou un acheteur public pose toujours — et il a raison de les poser.
Sur quoi ça se branche. Un système d'agents ne remplace pas le SI existant, il s'y intègre : ERP, logiciel métier, messagerie, outils maison. L'architecture écrite nomme chaque point de contact et ce qui y transite.
Où vivent les données. La frontière est tracée noir sur blanc : ce qui reste dans l'infrastructure, ce qui passe par un service externe, et ce qui ne sort jamais. C'est là que se traitent le RGPD et la souveraineté — pas dans une clause générale de bonne volonté.
Ce que ça coûte à l'usage. Un agent consomme à chaque exécution. L'architecture fixe les plafonds et le comportement au plafond : un coût d'usage non borné n'est pas un coût, c'est une surprise datée.
Le chiffrage du chantier se signe sur cette architecture — prix fixe, pas de régie déguisée.
3. Le banc de recette — les cas qui doivent passer
Une démo réussie prouve qu'un scénario passe une fois. Un banc de recette prouve que les scénarios convenus passent encore — aujourd'hui, et après chaque évolution.
Le banc, c'est la spécification traduite en cas concrets : les dossiers types, les cas limites, les refus attendus. La recette de livraison se fait contre ce banc, pas contre l'enthousiasme d'une réunion. Et quand le système évolue en run, chaque évolution est livrée contre le même banc, rejoué. C'est ce qui fait la différence entre maintenir un système et espérer qu'il tienne.
4. La provenance — d'où vient chaque livrable
Dernière pièce, la plus simple à énoncer : tout ce qui est livré est tracé. Quel code, quelle version, quelle date, quelle validation. Le code est livré au client, la documentation avec, et le droit de sortie est écrit au contrat — vous partez avec le système, pas avec une dépendance.
La réversibilité n'est pas un argument commercial. C'est une pièce du dossier.
Pourquoi « opposable »
Le mot vient du vocabulaire juridique, et il est choisi exprès. Une pièce opposable, c'est un écrit qu'on peut invoquer face à l'autre partie — et qui vous engage autant qu'elle. C'est exactement le niveau d'exigence des chantiers IT sérieux : cahier des charges, recette, procès-verbal. Nous appliquons ce niveau-là aux systèmes d'agents, parce que c'est le seul qui permette à un décideur d'engager sa signature sur autre chose qu'une impression.
Et parce qu'une méthode ne vaut que testée : notre propre agence tourne sur son propre système agentique — prospection, production, pilotage. Chaque pièce décrite ici existe pour notre propre chantier interne avant d'être proposée à un client. C'est notre banc d'essai permanent, et notre première preuve.
La démonstration s'arrête là où commence l'écrit. Le reste, ce sont les quatre temps de la méthode — audit, architecture, mise en production, run — détaillés page La méthode.
