Construire sur votre stack existante : le schéma de déploiement qui fait vraiment « composer » l’IA

Le moyen le plus sûr de perdre un an avec l’IA (intelligence artificielle) consiste à la traiter comme une boîte à outils maline que chacun peut « tester » dans son coin. Vous obtenez un surcroît d’énergie, quelques prompts impressionnants, et un désordre discret : accès aux données éclatés, réponses incohérentes, et une équipe sécurité qui découvre les usages après coup.

Si l’expression « build on the stack you have » revient si souvent, c’est précisément parce qu’elle dit l’inverse. C’est une contrainte qui oblige à se concentrer : utiliser les systèmes dans lesquels les équipes travaillent déjà, et faire en sorte que l’amélioration ressemble à une mise à niveau de workflow, pas à un nouveau métier.

Cette idée ressortait très clairement d’un article de SaaStr sur un playbook partagé par des dirigeants très différents, chez Atlassian, Anthropic et Scale, qui convergent tous vers le fait d’intégrer l’IA dans les outils et les processus sur lesquels les entreprises opèrent déjà. J’en partage l’orientation. Mais je pense que la plupart des équipes échouent au moment de traduire cette idée en exécution.

Voici donc la traduction opérationnelle : « build on the stack you have » est un schéma de déploiement d’opérateur. Il vous indique quoi standardiser, quoi arrêter, et comment mettre en place un petit groupe capable de transformer des pilotes en assets de workflow qui composent dans le temps.

La tension : les pilotes paraissent peu coûteux, le désordre ne l’est pas

Les pilotes séduisent parce qu’ils sont faciles à lancer. Quelqu’un ajoute une extension de copilot, ouvre un workspace LLM, colle quelques documents, et annonce une victoire. Pas de réunion budgétaire. Pas d’intégration. Pas de conversations difficiles.

Puis la facture arrive dans une autre monnaie : retouches, défiance et risques invisibles.

• Retouches : les équipes ne reproduisent pas les résultats des autres ; chaque « win » relève d’un savoir-faire individuel, pas d’une capacité répétable.

• Défiance : quand deux assistants répondent différemment à la même question, l’organisation en tire la mauvaise leçon : l’IA est aléatoire, donc on l’ignore.

• Risque invisible : les chemins d’accès se multiplient. Les données transitent via des outils non maîtrisés. Personne ne sait expliquer quoi a été utilisé, où.

La solution n’est pas d’ajouter « plus de gouvernance » comme posture. La solution, c’est un petit nombre de standards qui créent un control plane partagé, et la capacité à retirer les alternatives qui le contournent.

Standardisez quatre sujets tôt (ou vous paierez indéfiniment)

Si vous voulez que l’IA compose, standardisez ce qui la rend pilotable. Vous pouvez laisser les équipes varier sur les prompts et les tests d’interface. Mais ne les laissez pas varier sur l’identité, les droits, la documentation et l’évaluation.

1) Identité : un utilisateur, une traçabilité

Chaque interaction qui compte doit être attribuable. Pas pour contrôler, pour apprendre. Si vous ne pouvez pas relier un résultat à un utilisateur et à un contexte, vous ne pouvez ni diagnostiquer les échecs ni diffuser ce qui marche.

L’identité est aussi ce qui maintient l’IA dans votre stack. Le single sign-on n’est pas une case à cocher. C’est la frontière entre « c’est notre outil » et « c’est un usage parallèle ».

2) Droits : moindre privilège, aligné sur les workflows

La plupart des modèles de droits sont conçus pour des humains qui cliquent dans des écrans. L’IA change la nature des accès, parce qu’elle peut traverser plusieurs systèmes et en synthétiser le contenu.

La question n’est donc pas « l’assistant peut-il lire ce dossier ? ». C’est : « peut-il exécuter cette action dans ce workflow, avec cette piste d’audit ? ». Si votre modèle de droits ne reflète pas les frontières des workflows, vous finirez soit par tout bloquer, soit par tout exposer.

Règle pratique : démarrez restrictif, puis ouvrez au fur et à mesure, sur la base d’une valeur observée et de chemins contrôlés. Il est beaucoup plus simple d’ajouter des accès que de revenir en arrière une fois que le contenu s’est diffusé dans des prompts, des notes et des exports.

3) Documentation : traiter prompts et workflows comme un produit

La documentation est l’endroit où les pilotes vont mourir — ce qui rend la standardisation indispensable.

Vous avez besoin d’un lieu où une amélioration de workflow devient compréhensible et réutilisable par l’équipe suivante. Pas « voici mon prompt », mais « voici le job à accomplir, voici le contrat d’entrée, voici la sortie attendue, voici le mode de défaillance ».

Faites de l’unité de réutilisation une workflow card :

• Déclencheur : quand l’utiliser ?

• Entrées : sur quels systèmes et quels champs s’appuie-t-elle ?

• Sortie : à quoi ressemble un résultat « bon » ?

• Escalade : quand un humain doit-il reprendre la main ?

• Owner : qui la met à jour quand le processus évolue ?

C’est le même muscle que pour livrer des fonctionnalités : des contrats clairs valent mieux que la connaissance implicite.

4) Evals : un dispositif simple vaut mieux que des débats sans fin

Sans evals, chaque discussion se réduit à une préférence. Avec des evals, vous améliorez un workflow comme vous améliorez un logiciel : mesurer, modifier, remesurer.

Gardez-le simple au départ :

• Golden set : 20 à 50 exemples réels issus du workflow.

• Scoring rubric : ce que signifie « correct » (et ce qui est inacceptable).

• Regression checks : quand les prompts, le retrieval ou les modèles changent, relancez.

Si vous livrez déjà du logiciel, cela devrait vous sembler familier. D’ailleurs, les adoptions les plus rapides que j’ai observées ont démarré le jour où les équipes ont cessé de parler de « qualité de l’IA » et ont commencé à la traiter comme un système testable.

Supprimez deux choses sans ambiguïté : les shadow copilots et les réserves privées de connaissances

La standardisation ne fait que la moitié du travail. L’autre moitié, c’est la soustraction. Si vous voulez une capacité IA partagée, vous ne pouvez pas garder des outils parallèles qui la sapent.

Shadow copilots : la bifurcation silencieuse de votre organisation

Un shadow copilot, c’est tout assistant qui se trouve en dehors de votre modèle d’identité et de droits. L’intention peut être bonne. Il peut même être « accepté provisoirement ». Mais il crée trois bifurcations :

• Une bifurcation des chemins de données (qu’est-ce qui a été collé, et où).

• Une bifurcation des comportements utilisateurs (les équipes développent des habitudes différentes).

• Une bifurcation de la vérité (les réponses divergent, et personne ne sait pourquoi).

Soyez explicite : quels assistants sont autorisés, dans quels contextes, et lesquels ne le sont pas. Si vous ne tracez pas la ligne, vos meilleurs profils construiront autour de vous, et vos profils les plus prudents sortiront du jeu.

Réserves privées de connaissances : arrêtez de récompenser les « prompt whisperers »

Toute organisation fait émerger quelques power users qui obtiennent d’excellents résultats. L’échec classique consiste à les célébrer sans extraire l’actif.

Si un prompt ou une astuce de workflow a de la valeur, elle doit rejoindre la bibliothèque partagée, avec un owner et une cadence de mise à jour. Sinon, vous venez de créer une nouvelle dépendance à des personnes clés, déguisée en innovation.

Les incitations comptent, ici aussi. Si vous félicitez l’héroïsme, vous obtiendrez plus d’héroïsme. Si vous valorisez des workflow cards réutilisables, adoptées par d’autres, vous obtiendrez de la composition dans le temps.

L’organisation qui transforme des pilotes en assets qui composent

La plupart des « AI task forces » échouent pour une raison simple : elles sont dimensionnées pour explorer, pas pour intégrer. L’exploration est nécessaire. L’intégration, c’est ce qui transforme l’activité.

Vous voulez un petit groupe d’enablement, avec un mandat étroit : transformer des pilotes éprouvés en assets de workflow réutilisables, au sein de la stack que vous exploitez déjà. Pensez-y comme à de la productisation de workflows internes.

Voici une structure qui tient sous pression :

• Workflow owner (côté métier) : définit ce que signifie « bon », choisit les premiers cas d’usage, porte l’adoption.

• Intégrateur plateforme (engineering ou IT) : identité, droits, connecteurs, audit.

• Responsable évaluation (profil QA possible) : golden sets, rubrics, regression checks, revues d’incidents.

• Responsable conduite du changement : formation, documentation, communication de déploiement, boucles de feedback.

Pas une grosse équipe. Une interface claire. Et une règle : ce groupe ne produit pas des démos au hasard. Il livre uniquement des upgrades de workflow qui vivent dans les outils que les équipes ouvrent déjà tous les jours.

C’est aussi l’endroit où vous pouvez réutiliser des mécanismes de transformation qui évitent le « théâtre des silos ». Si vous souhaitez un dispositif de pilotage plus serré, j’ai écrit un article séparé sur cinq mécanismes qui évitent le théâtre des silos. La même logique s’applique ici : une clarté sur l’ownership, la cadence et les décisions l’emporte sur l’enthousiasme.

Un exemple vécu : le jour où l’on comprend que « pilot » est un choix de gouvernance

J’ai vu une organisation de R&D livrer plusieurs « assistants » en parallèle, chacun construit par des équipes brillantes qui voulaient aider. Ils fonctionnaient. Pris individuellement. Puis une release a modifié une dépendance commune, et personne n’a su s’accorder sur une amélioration ou une régression : chaque outil s’appuyait sur des prompts différents, des sources de contexte différentes, et des critères d’acceptation différents.

Nous n’avons pas résolu le problème en choisissant « le meilleur » assistant. Nous l’avons résolu en standardisant les evals et la documentation, puis en consolidant les outils en un seul chemin autorisé, avec des règles d’accès explicites. L’impact visible a été une baisse des débats. L’impact réel a été la vitesse : les améliorations ont cessé de repartir à zéro à chaque changement de modèle ou de prompt.

Le point est inconfortable, mais utile : les pilotes deviennent permanents quand on évite le travail difficile de standardisation. « Temporaire » signifie souvent « sans owner ».

Le schéma de déploiement que vous pouvez exécuter ce trimestre

Si vous voulez une séquence concrète, appliquez celle-ci :

1. Choisissez deux workflows dont la qualité de sortie est facile à juger et où la douleur de passation est réelle (triage du support, synthèses d’appels commerciaux vers le CRM, comptes rendus d’incidents, rédaction de PRD avec un template défini).

2. Définissez le contrat d’entrée : quels systèmes sont des sources autorisées, quels champs comptent, et ce qui est hors périmètre.

3. Installez le control plane : SSO, frontières de droits, piste d’audit. Aucune exception « juste pour cette équipe ».

4. Constituez un golden set à partir de cas réels et rédigez une rubric. Commencez petit. Rendez-le exécutable.

5. Livrez une workflow card dans l’outil principal (ticketing, CRM, docs, chat). Réduisez au minimum la friction d’usage.

6. Tenez une revue hebdomadaire : adoption, modes de défaillance, régressions, et une amélioration livrée.

7. Supprimez les alternatives qui contournent les standards. Restez courtois, fermes et rapides.

Si votre organisation raisonne déjà en termes de « control plane » pour l’IA, vous apprécierez peut-être aussi AI architecture isn’t a diagram. It’s an operator’s checklist. Le fil conducteur est identique : la fiabilité se conçoit, elle ne se décrète pas.

Mon point de vue : « build on the stack you have » relève d’une discipline, pas d’une préférence

Construire sur votre stack existante n’a rien à voir avec une posture conservatrice. Il s’agit de composition dans le temps. Quand l’IA vit dans votre identité, vos droits, votre documentation et vos evals, chaque amélioration devient réutilisable. Elle se diffuse via des workflow cards, pas via des conversations de couloir. Elle résiste aux changements d’effectifs. Elle devient plus sûre à mesure qu’elle devient plus utile.

Quand l’IA vit en dehors de la stack, vous pouvez aller vite pendant un mois. Puis vous passez les six suivants à nettoyer les conséquences et à tenter de reconstruire la confiance.

Si vous voulez une phrase pour guider vos décisions : standardisez le control plane, puis seulement ensuite laissez s’exprimer la créativité.

Et si vous êtes tenté de mesurer le succès en « heures économisées », je vous encourage à challenger ce réflexe. Le vrai objectif, c’est le throughput avec confiance. J’explore cette tension dans Stop Measuring AI by Hours Saved.

Le meilleur déploiement est celui qui rend le trimestre prochain plus simple que celui-ci. Voilà à quoi ressemble la composition dans le temps.