Maîtrisez ce qui est critique pour l’activité

L’IA devient une capacité opérationnelle au sein des entreprises. Dès que c’est le cas, une règle s’applique : ce qui est critique pour l’activité doit vous appartenir.

Vous utiliserez des plateformes, des outils d’automatisation, des fournisseurs de modèles et des prestataires. Vouloir tout construire vous-même n’est ni réaliste ni intelligent. Mais le contrôle et l’orchestration de vos systèmes d’IA doivent rester dans l’entreprise.

You can rent the hands. You never rent the capability.

La plupart des initiatives d’IA ne meurent pas après le pilote parce que le modèle est mauvais. Elles meurent parce que personne n’est propriétaire du système : la propriété est floue, l’orchestration est externe, l’exécution est éclatée et l’apprentissage part avec le prestataire.

Externaliser une IA critique pour l’activité, c’est une porte à sens unique déguisée en décision trimestrielle. On y entre pour pas cher, on en sort à prix d’or.

Le test de maîtrise, avant que le moindre travail d’IA ne quitte l’entreprise :

If losing this capability tomorrow would weaken the business, it never leaves the building.

Vérifiez ensuite les cinq verrous, comme le fait OG pour savoir si une entreprise maîtrise vraiment son IA :

• Modèle. Pouvez-vous changer de fournisseur sans réécrire vos applications ?
• Données. Vos données, vos tests et votre connaissance des processus sont-ils stockés dans un endroit que vous contrôlez ?
• Compétences. Vos propres équipes peuvent-elles modifier le système ?
• Coût. Savez-vous ce que coûte chaque modification ?
• Sortie. Pouvez-vous mettre fin au contrat et faire tourner le système dès le lendemain matin ?

Avant qu’un fournisseur ne construise votre IA, posez une seule question : qui la modifie après leur départ ? Faire tourner un système, c’est la partie facile. C’est dans sa modification que le coût se cache. La mise en production prouve que le système fonctionne. La première modification après le départ de ceux qui l’ont construit prouve à qui il appartient.

Avant le premier jour, et dans le contrat :

• Qui, dans mon équipe, est responsable de ce système après la mise en production ? Une personne nommée, pas le nom d’une équipe.
• À qui appartiennent le code, les prompts, les données et les tests d’évaluation ? Écrivez-le dans le contrat.
• Quelle est la date de sortie, et que doit prouver mon équipe d’ici là ?
• Une partie du paiement final dépend-elle d’une modification livrée par mon équipe seule ?

IAC.AI repose sur cette idée : la maîtrise d’abord, construire une capacité interne plutôt qu’une dépendance. Son objectif est l’autonomie du client. Le test s’applique d’abord à IAC.AI : « Si un client ne peut pas modifier ce que nous avons construit, nous n’avons pas fini le travail. » Conseil.