Le modèle est un consommable, votre contexte est l'actif

Regardez la trajectoire des deux dernières années. Un modèle sort, il devient la référence, les équipes réécrivent leurs intégrations autour de lui. Quelques mois plus tard, un autre le dépasse. Un troisième arrive, moins cher. Les écarts de qualité se resserrent, les interfaces se standardisent, le changement de fournisseur se fait en modifiant une variable d'environnement.

La conclusion pratique est brutale : le modèle est un consommable. Il se remplace, il se négocie, il se déprécie. Construire sa stratégie IA autour du choix d'un modèle, c'est construire autour de la pièce la plus volatile du système.

Ce qui ne se remplace pas

Ce qui ne se remplace pas, c'est le contexte de votre entreprise. Autrement dit, tout ce qu'un modèle générique ignore et qu'il faut lui fournir pour qu'il devienne utile chez vous.

• Vos données propres : historique client, catalogue, documentation, échanges, décisions passées.
• Vos process écrits : qui fait quoi, dans quel ordre, avec quelles exceptions.
• Vos règles métier explicitées : ce qu'est un bon lead chez vous, ce qui déclenche une escalade, ce qui est refusé.
• Votre design system et votre voix : ce qui fait qu'un contenu ressemble à votre marque et pas à une sortie générique.
• Vos prompts et instructions, testés sur vos cas réels et corrigés au fil du temps.
• Vos automatisations : les tuyaux qui relient vos outils et qui portent l'exécution.
• Vos jeux d'évaluation : les exemples annotés qui vous permettent de dire si un changement améliore ou dégrade.

Cet ensemble a une propriété que le modèle n'a pas : il s'accumule. Chaque correction, chaque exception documentée, chaque exemple annoté l'améliore de façon permanente. Il n'est pas déprécié par la sortie du modèle suivant — il en profite immédiatement.

Le moat n'est pas dans la technologie, il est dans la spécificité

Tout le monde a accès aux mêmes modèles, aux mêmes API, souvent aux mêmes outils d'orchestration. Il n'y a donc aucun avantage concurrentiel à en utiliser un plutôt qu'un autre. L'avantage naît de ce que vous seul possédez : la connaissance fine de votre métier, formalisée dans un format exploitable par une machine.

La question n'est pas « quel modèle utilisez-vous ? » mais « qu'avez-vous accumulé qu'un concurrent ne peut pas acheter ? ».

Un concurrent peut acheter le même abonnement le jour même. Il ne peut pas acheter vos deux cents cas de qualification annotés, vos règles d'escalade affinées par l'usage, ni votre bibliothèque d'instructions qui produit des contenus qui vous ressemblent.

Construire cet actif comme du code

Un actif qui vit dans la tête de trois personnes ou dans l'historique d'une conversation n'est pas un actif : c'est un risque. Traitez le contexte comme vous traitez du code.

Écrit, versionné, possédé

1. 01Écrivez-le dans des fichiers, pas dans des interfaces de configuration propriétaires.
2. 02Versionnez-le : un dépôt, un historique, la possibilité de revenir en arrière et de voir qui a changé quoi.
3. 03Hébergez-le sur vos comptes, avec vos accès. Le prestataire travaille dessus, il ne le détient pas.
4. 04Testez-le : un jeu de cas réels et une sortie attendue par cas, rejoués à chaque modification.
5. 05Documentez les décisions : pourquoi cette règle existe, quel incident l'a provoquée.

Avec cette discipline, changer de modèle devient une opération de routine : vous rejouez vos cas d'évaluation sur le nouveau, vous comparez, vous basculez ou non. Sans elle, chaque changement est un projet.

Pourquoi « externaliser à une boîte IA » se retourne souvent

Le schéma classique : une entreprise confie son sujet IA à un prestataire, qui livre un chatbot ou un agent qui fonctionne. Six mois plus tard, il faut faire évoluer une règle. Personne en interne ne sait où sont les instructions. Les automatisations tournent sur le compte du prestataire. Les jeux de test n'existent pas. Le savoir accumulé pendant le projet — les exceptions, les arbitrages, les cas tordus — est resté chez le prestataire.

Le livrable fonctionnait, mais l'entreprise n'a rien capitalisé. Elle a loué un résultat au lieu de construire un actif. Et si elle change de prestataire, elle recommence.

Ce n'est pas un argument contre l'externalisation : peu d'organisations ont en interne la compétence pour construire tout cela seules, et attendre de l'avoir coûte plus cher que de faire appel à quelqu'un. C'est un argument sur le contrat. Ce qui doit être exigé, ce n'est pas « livrez-nous un agent », c'est « livrez-nous un agent, ses instructions, ses tests, sa documentation, sur nos comptes, et formez nos équipes ».

Trois questions à poser avant de signer

• Sur quels comptes tournera ce qui sera construit — les nôtres ou les vôtres ?
• Que reste-t-il chez nous, précisément, le jour où la mission s'arrête ?
• Comment saurons-nous, dans six mois, si un changement de modèle améliore ou dégrade le résultat ?

Si les réponses sont floues, le projet produira une démonstration, pas un actif.

L'approche DL : le Skill Pack de marque

C'est la raison pour laquelle nous structurons nos missions autour de ce que nous appelons un Skill Pack de marque : l'ensemble écrit, versionné et transféré de ce qui rend l'IA utile chez vous — instructions, contexte métier, règles de qualification, éléments d'identité, automatisations et documentation d'exploitation.

La conséquence est assumée : à la fin d'une mission, le code, les comptes, les automatisations et la documentation vous appartiennent, et vos équipes sont formées pour continuer sans nous. Un prestataire dont vous ne pouvez pas vous passer n'est pas un partenaire de croissance, c'est une dépendance.

Ce qu'il faut retenir

Ne construisez pas votre stratégie autour d'un modèle : il aura changé avant la fin de votre projet. Construisez-la autour de ce que vous accumulez — contexte, règles, exemples, automatisations, documentation. C'est le seul élément du système qui prend de la valeur avec le temps, et c'est le seul que personne ne peut vous copier.