Notre thèse
La dépendance est un choix
Par Raphaël-David Lasseri et Thomas A. Epalle
Publié le
Mis à jour le
Une entreprise adopte un assistant pour préparer ses réponses clients. Les gestionnaires s’y habituent, puis les procédures passent dans l’outil, jusqu’aux exceptions que seuls les plus anciens connaissaient. Un jour, le fournisseur augmente ses tarifs ou retire le modèle utilisé. L’entreprise découvre alors ce que coûterait un changement : l’abonnement n’était qu’une petite partie de ce qu’elle avait engagé, et une partie de son savoir-faire se trouve désormais dans l’outil.
Personne dans cette entreprise n’a décidé de dépendre de ce fournisseur. Chaque étape semblait raisonnable, qu’il s’agisse de gagner du temps ou d’éviter un développement, et à chaque étape une autre décision était possible. C’est en ce sens que nous parlons de choix.
Toute organisation dépend de technologies et d’expertises qu’elle ne produit pas elle-même, et la plupart de ces dépendances sont raisonnables. Encore faut-il en connaître les conséquences et savoir comment en sortir. Pour nous, la souveraineté consiste à choisir ses dépendances et à garder les moyens de revenir sur ces choix.
Où la valeur s’accumule
Dans un projet d’IA, une organisation apporte ses données, le temps de ses équipes et sa connaissance du métier. Sans cette connaissance, personne ne saurait distinguer une réponse juste d’une réponse qui en a seulement l’air.
Nous concevons nos projets pour qu’elle en garde quelque chose une fois le projet terminé, notamment des règles métier écrites et des critères pour évaluer les réponses. Ces acquis doivent rester valables si le modèle ou le fournisseur change. Quand nous comparons des solutions, nous chiffrons donc aussi ce qu’il en coûterait de les faire évoluer ou de les remplacer.
Il faut aussi regarder toute la chaîne. Un service hébergé en France peut reposer sur un modèle dont l’accès reste contrôlé par un fournisseur extra-européen, et les données partent souvent plus loin que prévu, chez le fournisseur ou chez ses sous-traitants. Reste à savoir comment continuer à travailler si l’outil devient indisponible.
Pour une administration ou une unité de la défense, cette question se pose déjà. En juin 2026, un fournisseur américain a suspendu pendant près de trois semaines l’accès à ses modèles les plus avancés pour respecter des contrôles à l’export. Le droit impose par ailleurs à l’administration de pouvoir communiquer à une personne les règles d’un traitement algorithmique qui a fondé une décision la concernant. Nous intégrons ces contraintes dans l’architecture dès le départ, au même titre que la performance.
Conserver la capacité de juger
La dépendance la plus discrète concerne les compétences. Nous l’appelons dépendance cognitive : une organisation délègue des tâches et perd peu à peu les moyens d’en juger les résultats.
Le premier signe est souvent un juriste qui ne sait plus contester l’assistant qu’il utilise. Ensuite, la relecture devient une formalité, et les nouveaux arrivants apprennent à interroger l’outil sans apprendre ce qui leur permettrait de le contrôler.
Les tableaux de bord ne montrent rien de tout cela : quand le taux de correction d’un assistant tombe à zéro, impossible de savoir si l’outil est devenu excellent ou si plus personne ne relit. Faire valider par un humain n’y change pas grand-chose si cette personne n’a ni le temps, ni la compétence, ni l’autorité de contester la réponse.
L’outil peut aussi aider à garder ce niveau. Un assistant qui cite ses sources et signale ce dont il n’est pas sûr oblige son utilisateur à se faire un avis sur le dossier. C’est dans ce sens que nous concevons les usages.
Mettre les résultats à l’épreuve
La recherche en physique nous a laissé une habitude : avant de travailler, dire ce que nous cherchons à montrer, comment nous allons le mesurer et ce qui nous ferait changer d’avis. Nous testons ensuite les approches sur des cas réels du client, en commençant par chercher ceux où elles échouent.
Quand nous envisageons un agent, c’est-à-dire un logiciel qui enchaîne des actions à l’aide d’un modèle d’IA, nous le comparons d’abord à une automatisation simple ou à un modèle statistique. S’il ne fait pas mieux, nous l’écartons. Il nous arrive aussi de conclure qu’un projet ne justifie pas d’IA du tout, et nous le disons avant tout engagement.
Pour un outil qui traite des demandes, nous mesurons le temps qu’il faut pour obtenir un dossier correctement traité, relecture et corrections comprises. Le choix entre un logiciel du marché, une adaptation et un développement sur mesure se fait de la même façon, sur le coût complet, en tenant compte de l’exploitation.
Le temps gagné n’a de valeur que s’il sert à quelque chose, par exemple à résorber un retard ou à raccourcir un délai de réponse. Quand les effets d’un projet peuvent être mesurés et attribués, nous proposons qu’une part de notre rémunération dépende des résultats convenus ensemble. Nous partageons alors le risque, et nous avons intérêt, comme le client, à ce que ce temps soit bien employé.
Transmettre la maîtrise
Tout cela vaut aussi pour nous. Dès le départ, le contrat précise ce qui appartient au client, ce qu’il peut récupérer et à quelles conditions une autre équipe peut reprendre le projet. La documentation et la formation font partie du projet, pour que les équipes connaissent les limites du système et sachent juger ce qu’il produit.
Quand une cellule IA interne est utile pour démarrer, nous la concevons pour transmettre ses compétences aux métiers en trois ans environ, plus ou moins selon le point de départ de l’organisation. Elle a réussi si, au bout de ce temps, les services se débrouillent sans elle. Certaines fonctions resteront aux spécialistes, comme l’exploitation des modèles ou la sécurité, mais juger un résultat et décider quoi en faire revient aux équipes métier, qui en portent la responsabilité.
Notre travail consiste à rendre ces choix visibles avant qu’ils ne soient faits par défaut.