Former, pas rendre dépendant

Il existe un business model très rentable dans la tech : construire des systèmes que vous seul savez maintenir.

Vous livrez quelque chose d'impressionnant. Votre client ne comprend pas ce qui tourne sous le capot. Il revient vous appeler quand quelque chose se casse, quand il faut évoluer, quand quelqu'un a cliqué là où il ne fallait pas. C'est un flux de revenus récurrent. C'est parfaitement rationnel du point de vue du prestataire.

Ce n'est pas ma méthode.

Le piège de la boîte noire

L'intégration IA suit souvent ce schéma. Une agence déploie un chatbot. Un freelance monte un workflow. Un éditeur installe sa solution en SaaS. Et à la fin, votre organisation a un système qui fonctionne — tant que vous payez la maintenance, tant que l'éditeur existe, tant que le seul ingénieur qui comprend ce que ça fait est encore là.

Ce n'est pas une intégration. C'est une dépendance habillée en projet. Le problème n'est pas technique — il est culturel. On a confondu livrer et transmettre. Ce sont deux choses très différentes.

Ce que j'ai appris avec l'art

Depuis 18 ans, je déploie des installations artistiques qui doivent fonctionner sans moi. Un motif génératif qui tourne en boucle dans une médiathèque pendant 3 semaines. Une borne d'arcade dans un festival à l'autre bout du monde. Une expérience VR dans un espace que je ne reverrai peut-être jamais.

Pas de technicien permanent sur place. Pas de joignabilité à toute heure. Pas le droit de laisser quelque chose de fragile.

Si le régisseur de la salle ne peut pas redémarrer le système seul, le système est mal conçu.

Cette règle, je l'applique à l'IA en entreprise.

La transmission comme critère de qualité

Quand je déploie un agent IA, le travail n'est pas terminé quand l'agent tourne. Il est terminé quand une personne de l'équipe comprend ce qu'il fait, sait le modifier, et pourrait expliquer son fonctionnement à un collègue. C'est un critère de qualité, pas une option. Concrètement :

— L'architecture est documentée en français, pas en jargon.
— Les déclencheurs et conditions sont lisibles par un non-développeur.
— Une session de transfert est incluse dans chaque mission — pas une démo, une vraie passation de clés.
— Je construis avec des outils que l'organisation peut maintenir, pas avec des outils qui me donnent l'avantage sur elle.

Un différenciateur, pas une contrainte

On pourrait croire que rendre le client autonome fait perdre des missions. C'est une erreur de calcul. D'abord parce que l'autonomie ne vient pas facilement : savoir adapter un agent, savoir quand appeler à l'aide et sur quoi, ça s'apprend — la session de transfert n'est pas la fin de la relation, c'est le début d'une relation honnête.

Ensuite parce que les organisations qui comprennent ce qu'elles ont déployé font confiance pour aller plus loin. Ce n'est pas le client qui revient parce qu'il est coincé — c'est le client qui revient parce qu'il a vu un résultat et qu'il veut la prochaine tâche.

Le modèle de la dépendance produit des clients captifs. Le modèle de la transmission produit des clients qui choisissent de continuer.

L'IA ne remplace pas vos équipes — elle libère leur temps

Si vous déployez une boîte noire que personne ne comprend, vous avez créé une dépendance à une technologie qui peut évoluer, disparaître ou se retourner contre vous. C'est légitime d'en avoir peur. Si vous déployez un système que vos équipes comprennent, qu'elles peuvent modifier et dont elles sont propriétaires — vous avez automatisé une tâche, pas remplacé une personne. Et vous avez rendu à cette personne les heures qu'elle y passait, pour ce que seule une personne peut faire.

La transmission est la condition pour que l'IA soit un outil et pas une menace.