Changer de modèle sans refaire tout le workflow devrait devenir un objectif d’architecture

Le problème à résoudre avant l’outil

Une équipe veut tester un nouveau modèle mais découvre que toutes les règles sont noyées dans un agent monolithique. On pourrait traiter ça comme un simple réglage d’outil. Ce serait rater le sujet : les modèles évoluent vite. Si logique métier, prompt, données et actions sont soudés à un fournisseur, chaque changement devient un projet.

Une architecture IA se juge moins à la démo qu’à sa capacité à évoluer. Les modèles, les prix, les connecteurs et les règles changent vite. On peut gagner quelques semaines en enfermant toute la logique dans un composant, puis perdre des mois le jour où il faut le remplacer. Une stratégie robuste protège surtout les éléments que l’on veut garder quand l’outil change : règles, données, traces et interfaces. Le raisonnement tient sur un point assez concret : Les modèles évoluent vite. Si logique métier, prompt, données et actions sont soudés à un fournisseur, chaque changement devient un projet. C’est une manière classique de fabriquer du débit sans fabriquer davantage de valeur.

Commencer par le réel

Quelques faits récents évitent de raisonner dans le vide. En 2026, les agents d’espace de travail illustrent le passage du chatbot ponctuel à des flux répétables capables de mobiliser plusieurs sources et applications. Cette évolution déplace une partie du problème vers la gouvernance, le périmètre et le contrôle des actions. Google a annoncé en septembre 2026 des capacités agentiques transverses à Gmail, Drive, Docs, Sheets, Slides et Chat, avec génération de livrables à partir des sources autorisées et sous la direction de l’utilisateur. Il faut résister à la tentation de transformer un signal de marché en vérité locale. Ce qui compte vient ensuite : l’observation du processus.

La mesure utile tient d’abord dans cette consigne : séparer orchestration, données, règles métier et fournisseur de modèle. Compare le résultat accepté, pas seulement la première sortie. Les reprises racontent souvent l’histoire que la démo ne montre pas. Demande enfin si la personne responsable comprend encore comment le résultat a été obtenu. La vitesse sans lisibilité devient vite une dette.

Quatre contrôles simples

Séparer les règles métier du modèle et du fournisseur chaque fois que c’est raisonnable. On pourrait l’ignorer. Ce serait souvent la meilleure manière de recréer la charge un peu plus loin dans le processus.

Définir ce qui doit être exportable : données, configurations, historiques utiles, évaluations et journaux. L’intérêt est surtout de créer un critère observable. Si personne ne peut dire si ce point est respecté, la règle restera décorative.

Mesurer la qualité et le coût au niveau du résultat métier, pas au niveau d’un appel technique isolé. Le but n’est pas d’ajouter une couche de procédure. C’est de rendre visible la décision qui existait déjà, souvent de manière implicite.

Tester régulièrement un scénario de remplacement ou de panne d’une dépendance importante. Il faut alors sortir de la démonstration et suivre ce qui arrive réellement au dossier après la première réponse.

Le cas qui doit te faire arrêter

Il faut éviter un raccourci assez tentant. Le niveau de contrôle doit suivre la conséquence possible, pas l’enthousiasme pour l’outil. Une équipe veut tester un nouveau modèle mais découvre que toutes les règles sont noyées dans un agent monolithique. La bonne question dépend donc du contexte, de la fréquence et surtout du coût d’une erreur.

Une délégation technique n’est pas, à elle seule, un transfert de responsabilité. Plus le résultat est sensible, plus le niveau de preuve, de contrôle et de possibilité de reprise doit être explicite.

Une règle de sortie

Le bon réflexe n’a rien de spectaculaire : séparer orchestration, données, règles métier et fournisseur de modèle. C’est moins spectaculaire qu’une démo, mais beaucoup plus utile pour faire tenir l’usage dans le temps.