À qui appartiennent vos agents ? Propriété du code, du contexte et de la méthode

Une question revient rarement au moment du cadrage d'un projet d'agents IA. Elle revient toujours au moment du départ du prestataire. « Concrètement, qu'est-ce qui nous reste ? »

La réponse est souvent décevante. Un accès à une plateforme dont on ne maîtrise pas les règles. Des prompts stockés dans un compte SaaS. Une documentation qui décrit le quoi, jamais le pourquoi. Et une équipe interne qui n'a jamais eu les mains dans le moteur.

Le problème n'est pas juridique. Les contrats prévoient presque toujours une cession de droits sur les livrables. Le problème est opérationnel : on peut être propriétaire d'un actif sans être capable de l'exploiter. C'est la différence entre détenir un code source et savoir le faire évoluer.

Un agent en production, ce sont trois actifs distincts

Quand on parle de « propriété d'un agent », on mélange trois choses qui ne se transmettent pas de la même manière.

Le code. C'est la partie visible : les scripts d'orchestration, les appels aux modèles, les connecteurs vers vos systèmes, les règles de validation, la gestion des erreurs. C'est aussi la partie la plus facile à transférer — et la moins suffisante à elle seule.

Le contexte métier. C'est ce qui rend l'agent pertinent chez vous et inutilisable ailleurs. La nomenclature de vos familles d'achat. Les seuils de validation par montant. Les exceptions clients héritées de contrats signés en 2019. Les règles non écrites que votre responsable ADV applique depuis dix ans. Cet actif se construit pendant la mission, en interrogeant vos équipes. S'il n'est pas formalisé, il repart avec le consultant.

La méthode. C'est la capacité à recommencer. Comment a-t-on identifié les processus candidats ? Sur quels critères a-t-on écarté les autres ? Comment a-t-on défini les garde-fous, mesuré la qualité, décidé du passage en production ? Sans cette méthode, vous avez un agent. Avec elle, vous avez une capacité à en construire d'autres.

La propriété se décide au cadrage, pas à la sortie

Une clause de réversibilité signée en fin de contrat ne produit rien. La réversibilité est une contrainte de conception : elle change la manière dont on écrit le code, dont on documente les décisions, dont on associe les équipes internes.

Concrètement, cela se traduit par quelques choix structurants pris dès les premières semaines.

• Le dépôt de code est chez vous, dès le premier commit. Pas un transfert en fin de mission, mais un dépôt sur votre organisation Git, avec vos droits d'accès et votre historique complet.
• Les dépendances sont explicites et substituables. Un agent qui ne fonctionne qu'avec un modèle précis d'un fournisseur précis est une dépendance, pas un actif. Le code doit isoler l'appel au modèle derrière une interface.
• Le contexte métier vit dans le dépôt, pas dans les têtes. Règles, référentiels, cas limites, arbitrages : tout ce qui a été appris sur votre organisation est versionné au même endroit que le code.
• Au moins une personne de vos équipes participe aux revues techniques. Pas pour valider, pour comprendre.

Le contexte : l'actif qu'on oublie de réclamer

C'est le point le plus sous-estimé. Le code représente peut-être 20 % de la valeur d'un agent qui fonctionne. Le reste, c'est la connaissance du terrain qui a permis de le paramétrer correctement.

Un agent de traitement de commandes qui atteint 94 % de taux de reconnaissance ne doit pas ce chiffre à la qualité de son code. Il le doit au fait que quelqu'un a passé trois semaines à comprendre pourquoi 6 % des commandes sortaient du cadre, à quoi ressemblaient ces cas, et quelle règle appliquer.

Cette connaissance doit être écrite. Pas dans un rapport PowerPoint de fin de mission, mais dans des fichiers de configuration lisibles, commentés, rattachés aux cas qui les justifient. C'est ce qui permet à votre équipe, dix-huit mois plus tard, de comprendre pourquoi cette exception existe avant de la supprimer.

On ne peut pas automatiser le chaos. On ne peut pas non plus transmettre un contexte qui n'a jamais été formalisé.

Un exemple : la reprise en interne d'un agent de qualification

Une ETI industrielle de 340 personnes met en production un agent de qualification des demandes entrantes : tri, extraction des informations clés, routage vers le bon commercial, création de la fiche dans le CRM. Deux mois de mission, environ 600 demandes traitées par mois.

Sept mois plus tard, l'entreprise rachète un concurrent. Nouvelle typologie de clients, nouvelle gamme produits, nouveaux critères de routage. La question est simple : faut-il rappeler le prestataire ?

Non. Le responsable des systèmes d'information ouvre le dépôt, lit le fichier de règles métier — commenté, avec les raisons derrière chaque seuil —, ajoute les nouvelles familles de produits, ajuste la table de routage, lance la campagne de tests fournie avec le projet. Trois jours de travail interne.

Ce n'est pas une prouesse technique. C'est le résultat d'un choix fait au cadrage : la mission n'était pas de livrer un agent, mais de laisser une organisation requêtable et un actif maintenable.

Les questions à poser avant de signer

Quel que soit le prestataire que vous consultez, quatre questions permettent de situer rapidement le niveau de dépendance que vous acceptez.

• Où est hébergé le code, et à partir de quand ?
• Si nous changeons de fournisseur de modèle dans un an, que faut-il réécrire ?
• Quelle documentation du contexte métier sera livrée, et sous quelle forme ?
• Combien d'heures de nos équipes sont prévues dans le planning, et pour faire quoi ?

Si la dernière question surprend votre interlocuteur, vous avez votre réponse.