Le piège commence lorsqu’une plateforme achetée pour un assistant individuel devient, par inertie, la réponse à tous les futurs usages IA. On finit alors par confondre adoption rapide, automatisation transverse et produit métier.

Avant de comparer les fournisseurs, je clarifie trois choses : ce que l’entreprise peut acheter, ce qu’elle doit assembler et ce qu’elle doit pouvoir remplacer sans reconstruire son savoir métier. Ces réponses éliminent plus d’options qu’un long tableau de fonctionnalités.

Besoin dominantPoint de départÀ garder sous contrôle
Productivité individuelleSolution prête à l’emploiIdentité, sources et politique d’usage
Processus entre plusieurs métiersAutomatisation ou orchestrationÉtat, erreurs, permissions et fonctionnement quotidien
Produit différenciantExécution sur mesureLogique métier, expérience et évaluations

Un même fournisseur ne doit pas devenir toute l’architecture

Dans le programme bancaire que j’ai dirigé, la plateforme utilisée par les métiers, la doctrine de gouvernance, les connecteurs, la future AI Gateway et le registre remplissaient des fonctions différentes. Les enfermer dans un même choix de fournisseur aurait transformé un choix initial en architecture imposée.

L’interopérabilité n’est pas un objectif abstrait. Elle permet de conserver une règle validée, une action métier ou une évaluation lorsque l’outil d’exécution change. C’est pour cette raison que j’ai poussé une bibliothèque commune de connecteurs et de skills, utilisable par plusieurs produits plutôt que reconstruite dans chacun.

Je sépare cinq responsabilités

05Expérience et relais humains

Interface, confirmations, recours et traitement des erreurs.

04Exécution

Modèles, enchaînement des étapes, état et reprise.

03Logique métier

Règles, taxonomies, documents et connaissances de référence.

02Accès et permissions

Identité, données accessibles et actions réellement autorisées.

01Gouvernance et preuves

Registre, décisions, évaluations, journaux et supervision.

Des protocoles comme MCP peuvent rendre les connecteurs plus remplaçables. Ils ne décident ni des droits, ni du sens métier des actions, ni du niveau de contrôle. Cette responsabilité reste dans l’entreprise.

Six questions pour tester une plateforme

01

Identité et permissions

Le système agit-il avec les droits de la personne, d’un service ou d’un compte technique trop large ? Peut-on limiter une action, pas seulement une source de données ?

02

Ce que le connecteur permet vraiment

Expose-t-il une API brute ou une action comprise par le métier ? Qui maintient cette correspondance lorsque le système source change ?

03

Traces et reprise

Peut-on reconstruire ce qui s’est passé, avec quelle règle et quelle version ? Une erreur peut-elle être arrêtée puis reprise proprement ?

04

Réversibilité

Les règles, évaluations, connecteurs, contenus et traces peuvent-ils sortir dans un format réellement exploitable ?

05

Coût et fonctionnement quotidien

Qui surveille les coûts, les erreurs et les changements de modèles ? Que se passe-t-il lorsqu’une exécution reste bloquée à mi-chemin ?

06

Usage réel

Le système s’insère-t-il dans le travail existant ? Le temps de correction reste-t-il inférieur au temps gagné ?

Une démonstration réussie ne dit rien du fonctionnement en production. Les six questions s’inscrivent dans les fonctions Govern, Map, Measure et Manage du NIST AI RMF 1.0. Elles obligent surtout à regarder la vie du système après le pilote.

Je teste sur trois cas, jusqu’au résultat

Je prends un usage quotidien peu risqué, un processus qui traverse plusieurs outils et une action sensible. L’équipe va jusqu’au résultat exploitable, change une règle, inspecte les traces et simule une panne d’intégration.

Le test doit mesurer le temps de correction, pas seulement le taux de réussite. Une plateforme impressionnante sur le premier cas peut devenir très coûteuse sur les deux autres.

Ce qui doit rester à l’entreprise

J’achète volontiers les capacités génériques : modèles, stockage, recherche ou suivi technique. Je garde sous maîtrise les règles métier, les connecteurs validés, les évaluations et les décisions de produit. Ce sont ces éléments qui rendent le système utile et transférable.

Séparer ces responsabilités ne rend pas un changement de modèle instantané. Les comportements, les évaluations, les coûts et les seuils de contrôle doivent être revus. Mais la connaissance métier n’a pas à être reconstruite avec chaque fournisseur.

Si le fournisseur disparaît demain, que faut-il reconstruire ? Si la réponse comprend les règles, le contexte et les preuves, l’architecture a rendu l’entreprise captive.

Références de travail : architecture MCP 2026-07-28, NIST AI RMF 1.0.