Nous avons passé quatre articles à construire une architecture idéale. Sur le papier, tout est logique. Mais la réalité de l'entreprise est désordonnée. Les utilisateurs n'adoptent pas les outils, le Cloud coûte plus cher que prévu, et la sécurité dit "non" par réflexe.
Pour clore cette série – et suite à des retours de mes relecteurs m’indiquant que cela manquait d’exemples – j’aimerais imaginer des cas confrontés au réel. Raconter là où ça frotte, là où ça casse, et comment ce socle est censé aider. Que vous soyez banquier ou industriel, vos problèmes sont les mêmes : adoption, coût, sécurité, éthique.
Je ne vous mentirai pas : je n’ai pas encore déployé intégralement ce socle. Si vous vous en inspirez, faites-moi signe ! Mais pour sa conception, je me suis nourri de cas réels, en cherchant systématiquement les failles pour anticiper leur échec. Voici donc les scénarios que cette organisation est conçue pour prévenir, et les leçons à en retirer.
Leçon 1 : la technologie marche, c'est l'humain qui bug (le cas du "Projet Zombie")
On pense souvent que l'échec vient d'une hallucination de l'IA. Faux. L'échec le plus courant, c'est le silence : un outil techniquement parfait que personne n'utilise. Ce n’est pas un cas restreint à l’IA, c’est le fléau de toute transformation numérique.
- Le cas : un "Assistant de Connaissance RH" pour une grande entreprise de Retail.
- L'idée : un RAG (Type 2) indexant 500 PDF de procédures internes, accessible via une belle interface web dédiée.
- Le résultat : zéro adoption après 3 semaines. Un "Projet Zombie".
- L'intervention du socle : le problème n’est pas le modèle (Quadrant A), mais le Canal de Distribution (Article 3). Les employés ne vont jamais sur l'intranet.
- La solution : le Studio pivote l'architecture pour intégrer l'assistant directement dans Slack et Microsoft Teams. L'usage bondit de 0 à 4000 requêtes/jour.
Leçon 2 : ce qui est "Rentable" n'est pas toujours "Scalable" (Le piège du FinOps)
En phase d'exploration (Fonderie), on utilise les modèles les plus puissants (GPT-4, Claude 3.5 Sonnet) car on veut prouver la valeur. Mais quand on passe à l'échelle, la facture explose.
- Le cas : un "Agent de veille IT" qui scanne le web et les repos Git pour proposer des mises à jour de sécurité.
- Le problème : l'agent tourne en boucle, consommant des millions de tokens pour scanner des pages souvent inutiles. Le coût mensuel pour une équipe de 10 devs devient non viable.
- L'intervention du socle : le passage en phase d'industrialisation (Article 2) déclenche une revue FinOps obligatoire.
- La solution : on remplace le "gros modèle" généraliste par un "petit modèle" open-source (SLM), hébergé en interne et spécialisé uniquement sur le code.
À retenir : le rôle du Studio est parfois de dire : "C'est génial, mais on ne peut pas se le payer". La frugalité est une contrainte d'architecture.
Leçon 3 : la souveraineté n'est pas une option, c'est une architecture (le mur de la sécurité)
Dans la Banque ou la Défense, la réponse par défaut de la DSI est "Non". Le risque de fuite de données vers des acteurs américains est bloquant.
- Le cas : synthèse de documents confidentiels (Défense / M&A Finance).
- Le blocage : impossible d'envoyer les documents vers une API, même avec des souscriptions "Entreprise".
- L'intervention du socle : la Matrice de Criticité (Article 3) classe le projet en Quadrant D (Critique/Sensible). Cela n'interdit pas le projet, cela impose une architecture spécifique.
- La solution : déploiement déconnecté d'Internet (Air-gapped). On amène le modèle à la donnée, et non la donnée au modèle.
À retenir : la gouvernance ne sert pas à interdire, elle sert à définir les conditions techniques du "Oui".
Leçon 4 : l'IA ne remplace pas l'expert, elle le "dés-abrutit" (Le changement de paradigme)
C'est la peur numéro 1 : "L'IA va prendre mon job". Mon expérience montre l'inverse : l'IA prend la partie du job que l'expert déteste.
- Le cas : auditeur Contractuel (Légal) utilisant un pattern "Map-Reduce" pour analyser 200 pages de contrats.
- La friction : les avocats craignaient que l'IA ne rate une clause subtile et que leur responsabilité soit engagée.
- L'intervention du socle : le principe de Responsabilité Distribuée (Article 1). L'IA n'est pas "décisionnaire", elle n’est qu’un outil de pré-traitement.
- La solution : l'outil surligne les risques, mais oblige l'avocat à valider/invalider chaque alerte. On transforme une tâche de lecture (4h) en tâche de validation (30 min). L'avocat passe plus de temps à conseiller son client et moins à lire des alinéas.
À retenir : l'IA ne remplace pas l'humain, elle le transforme en architecte de la décision.
Leçon 5 : parfois, le plus grand succès est de tuer le projet (L'alignement éthique)
Un framework qui dit "Oui" à tout ne sert à rien. Sa vraie valeur se mesure aux projets qu'il arrête avant qu'ils ne fassent des dégâts.
- Le cas : une IA négociatrice pour le Retail, négociant en autonomie les prix fournisseurs.
- Le problème : techniquement, ça marche. Financièrement, c’est brillant. Mais lors des tests, l'IA se montre "brutalement efficace" : pour suivre sa directive de baisse de prix, elle froisse des partenaires historiques par manque de tact.
- L'intervention du socle : le Triple Circuit de Vigie (Article 4) remonte des signaux faibles de mécontentement fournisseur dès la phase d'Incubation.
- La décision : le gain financier immédiat ne vaut pas le risque réputationnel à long terme.
À retenir : une "fausse bonne idée" peut coûter très cher. Le Studio IA est aussi là pour protéger l'actif le plus précieux de l'entreprise : sa réputation.
Conclusion
Au terme de ces 5 articles, j'espère vous avoir convaincu d'une chose : L'IA en entreprise n'est pas un problème technologique.
La technologie est prête, même si elle change très vite. Les modèles sont là et ils sont de plus en plus performants. Le vrai défi, c'est l'organisation de votre entreprise. C'est de créer un système capable d'absorber cette puissance, de la diriger vers les endroits où la création de valeur sera la plus forte, et de la contrôler là où c'est dangereux.
Cette architecture (Studio, Fonderie, Matrice, Vigie) n'est pas une recette magique. C'est un organisme vivant qui doit évoluer, apprendre et s'adapter à votre organisation et au contexte fluctuant des technologies. De la même manière que vos équipes. Alors, arrêtez de regarder les modèles, et commencez à regarder votre organisation. C'est là que tout se joue.
Précédemment
Thomas François-Raketamanga
Thomas François-Raketamanga
Thomas François-Raketamanga
Thomas François-Raketamanga
