L’industrialisation de l’IA pousse aujourd’hui les entreprises à prendre des décisions techniques et organisationnelles beaucoup plus structurantes qu’il n’y paraît. Derrière le choix d’un modèle, d’une plateforme agentique ou d’un pipeline RAG, se jouent en réalité des questions de dépendance, de gouvernance et de capacité d’évolution à long terme.

À travers les projets menés chez Aiko, notamment autour des Diagnostics Data et IA, Christella Umuhoza partage ici plusieurs retours terrain observés auprès d’entreprises qui cherchent à industrialiser leurs usages IA sans perdre leur capacité d’arbitrage technologique.

Car la vraie question n’est plus “quel outil IA choisir ?”, mais plutôt : est-ce qu’on garde encore la liberté de choisir autrement demain ?

1. Pourquoi le sujet devient critique

L’IA industrialise plus vite que les entreprises ne se préparent réellement à l’accueillir.

Les investissements se concentrent naturellement sur les cas d’usage, les outils et les gains de productivité immédiats. Mais les décisions qui vont déterminer la capacité à faire évoluer ces systèmes dans deux ou trois ans — les choix de stack, d’orchestration, de dépendances — sont souvent prises sous contrainte de calendrier, avec une priorité simple : livrer vite.

Tant que l’IA reste au stade de pilote, les choix sont relativement réversibles. Les équipes testent plusieurs modèles, changent d’API, expérimentent des workflows.

Mais quelque chose change lorsqu’un premier cas d’usage entre réellement en production.

Quand une décision métier commence à dépendre d’un modèle. Quand un agent IA commence à agir au nom de l’entreprise : qualifier des leads, envoyer des emails, interagir avec des clients ou déclencher des opérations. À ce moment-là, les choix technologiques cessent d’être des hypothèses et deviennent des engagements durables, souvent plus difficiles à défaire qu’on ne l’imagine.

La question n’est alors plus uniquement technique. Elle devient stratégique : comment construire une stack IA capable d’évoluer dans un marché qui change tous les mois, sans perdre sa capacité d’arbitrage ?

2. Les risques sont réels et déjà visibles

Le sujet du risque dans l’IA est parfois perçu comme théorique. En réalité, les premiers signaux sont déjà visibles dans de nombreuses organisations.

Le premier risque est celui de la défaillance en cascade.

Un modèle change de comportement après une mise à jour. Une plateforme modifie ses conditions d’accès. Une API devient plus restrictive. Pour une entreprise dont certaines opérations dépendent déjà de ces systèmes, les conséquences sont immédiates : workflows interrompus, tâches reprises manuellement dans l’urgence, réponses incohérentes envoyées aux clients, équipes incapables d’identifier rapidement l’origine du problème.

La continuité de service, considérée comme acquise dans les systèmes traditionnels, devient beaucoup plus fragile dans un environnement IA fortement dépendant de composants externes.

C’est pour cette raison qu’avant même de recommander une stack à un client, il devient nécessaire de cartographier les points de défaillance : quels composants sont critiques, lesquels disposent d’alternatives crédibles, et surtout ce qui se passe opérationnellement lorsqu’un maillon devient indisponible.

Un autre risque, plus silencieux, est celui du lock-in progressif.

Au départ, les décisions semblent rationnelles. Une entreprise utilise la plateforme déjà intégrée à son environnement cloud, déjà contractualisée, déjà connue des équipes. Quelques mois plus tard, toute la logique métier dépend de cette couche : les workflows sont écrits pour ce runtime, les agents utilisent des connecteurs spécifiques, les pipelines de données reposent sur des formats propriétaires.

Le problème n’apparaît pas au moment de l’intégration. Il apparaît lorsque l’entreprise souhaite changer.

À ce stade, migrer ne signifie plus remplacer un outil. Cela signifie réécrire des pans entiers du système dans un contexte où la production dépend déjà de ces workflows.

La portabilité devient alors un sujet critique. Chaque composant introduit dans la stack devrait pouvoir être remplacé sans remettre en cause l’ensemble de ce qui a déjà été construit autour.

À cela s’ajoute une caractéristique propre aux systèmes IA : leur opacité.

Un système orchestrant plusieurs modèles, agents et pipelines ne suit pas toujours le même chemin pour accomplir une tâche identique. Deux exécutions sur les mêmes données peuvent produire des résultats différents. Cette non-détermination n’est pas une anomalie ; elle fait partie du fonctionnement même des systèmes génératifs.

Le problème n’est donc pas uniquement la variabilité des résultats. Le problème est l’incapacité à comprendre précisément où un comportement a dérivé.

C’est ce qui rend l’auditabilité critique. Une architecture qui ne permet pas de tracer les décisions, d’observer les chaînes d’exécution et d’identifier les écarts devient extrêmement difficile à maintenir dans le temps.

3. Pourquoi le lock-in IA est différent du SaaS

Les entreprises connaissent déjà le vendor lock-in dans le SaaS traditionnel. Migrer un CRM, un ERP ou un outil collaboratif est souvent long et coûteux, mais le chantier reste relativement prévisible : on déplace des données, des utilisateurs et des processus.

Dans une stack IA, la logique est différente.

Le lock-in ne se limite plus à une interface ou à un stockage de données. Il se diffuse dans plusieurs couches simultanément.

Les modèles ne sont qu’un point de départ. Autour d’eux gravitent des systèmes d’orchestration, des frameworks agentiques, des couches mémoire, des pipelines RAG, des outils d’évaluation, des mécanismes de routing entre agents et des connecteurs vers les systèmes métier de l’entreprise.

Le prompting, les guardrails, les workflows d’exécution, la manière dont les agents se coordonnent entre eux : tout cela est souvent construit autour des spécificités d’une plateforme donnée.

Contrairement à un export CSV dans un SaaS classique, cette logique métier encodée n’est pas portable par défaut.

Changer de plateforme peut impliquer de reconstruire :
la logique d’orchestration, les mécanismes mémoire, les connecteurs, les pipelines de données, les règles de supervision ou encore les mécanismes d’observabilité.

À cela s’ajoute une autre différence majeure : les systèmes IA évoluent en permanence.

Un modèle mis à jour peut produire des réponses différentes sur les mêmes entrées. Une fonctionnalité considérée comme stable peut se comporter différemment quelques semaines plus tard. Cette dérive est souvent découverte uniquement lorsqu’elle a déjà produit des effets visibles dans les opérations métier.

Dans le SaaS traditionnel, les interfaces changent lentement. Dans l’IA, le comportement même du système peut changer sans prévenir.

4. Cartographie des risques dans la stack IA

Une stack qu’on ne comprend pas de bout en bout est une stack qu’on ne contrôle pas réellement.

Et dans les architectures IA modernes, la dépendance se construit à plusieurs niveaux simultanément.

Le premier niveau est celui du modèle de base. Lorsqu’une application dépend fortement d’un modèle spécifique, chaque mise à jour devient un risque potentiel de régression. Une structure de réponse change, une formulation évolue, un comportement devient moins fiable sur certains cas.

Mais paradoxalement, le modèle n’est pas toujours la couche la plus difficile à remplacer.

Aujourd’hui, la dépendance la plus forte se situe souvent dans les couches d’orchestration et d’exécution.

Les workflows construits sur des runtimes propriétaires ne se déplacent pas facilement d’une plateforme à l’autre. La manière dont les composants communiquent, gèrent les états intermédiaires, exécutent des outils ou coordonnent plusieurs agents est profondément liée à l’architecture de la plateforme utilisée.

C’est généralement à cet endroit que les dépendances les plus coûteuses apparaissent.

La data layer représente également une zone de risque importante.

Les embeddings, index vectoriels et pipelines RAG encapsulent souvent des mois de structuration de connaissance métier. Lorsque ces systèmes reposent sur des formats propriétaires, les migrer peut devenir presque aussi coûteux que le projet initial lui-même.

La gouvernance et l’observabilité constituent un autre angle mort fréquent.

Sans logs structurés, sans traces des décisions prises par les agents, sans mécanismes d’évaluation continus, il devient difficile de détecter une dérive avant qu’elle ne produise des effets visibles.

Cette question dépasse d’ailleurs le simple monitoring technique. Elle touche directement à l’équilibre entre autonomie et contrôle.

Faut-il encoder davantage de logique déterministe pour sécuriser certains comportements ? Ou laisser les agents décider de manière plus autonome selon le contexte ?

En pratique, la plupart des entreprises naviguent entre ces deux approches. Elles ajoutent progressivement des règles backend, des garde-fous et des validations humaines au fil des comportements observés en production.

Enfin, il existe une dépendance souvent sous-estimée : la mémoire métier.

Les prompts, règles métier, ajustements opérationnels et logiques implicites vivent rarement dans une documentation structurée. Ils sont répartis entre différents fichiers, outils ou parfois dans la mémoire de quelques personnes clés.

Lorsque le contexte évolue ou que ces personnes quittent l’organisation, cette connaissance devient difficile à reconstituer. Et avec elle, une partie de la capacité à faire évoluer la stack.

5. Les principes d’une architecture IA résiliente

Une stack résiliente n’est pas une stack parfaite. C’est une stack qu’on peut comprendre, faire évoluer et réparer sans remettre en cause l’ensemble du système.

Le premier principe consiste à abstraire les dépendances.

Plutôt que de connecter directement les applications à un modèle ou à une plateforme spécifique, les architectures les plus robustes introduisent une couche intermédiaire standardisée. Cette abstraction permet de remplacer un fournisseur, de tester plusieurs modèles ou d’arbitrer entre coût et performance sans modifier toute la logique applicative.

Les entreprises les plus matures maintiennent d’ailleurs plusieurs fournisseurs actifs en parallèle. Non pas par indécision, mais pour conserver une capacité d’adaptation rapide lorsque le marché évolue.

Le deuxième principe est la planification des fallbacks.

Que se passe-t-il si un agent produit des résultats incohérents pendant plusieurs heures ? Si un provider devient inaccessible lors d’un pic d’activité ? Si les performances d’un modèle chutent brutalement ?

Ces scénarios doivent exister avant la crise.

Une architecture résiliente définit des seuils de détection, des niveaux de dégradation acceptables, des mécanismes de reprise manuelle et des procédures de supervision humaine.

Sans cela, la gestion des incidents devient improvisée.

Le troisième principe est l’observabilité continue.

Un système IA performant aujourd’hui peut se dégrader progressivement à mesure que les usages, les données ou les modèles évoluent. Cette dérive est encore plus difficile à détecter lorsque les équipes modifient continuellement prompts, règles et instructions pour corriger des comportements observés en production.

À force d’itérations rapides, beaucoup d’organisations perdent leur référence de base. Elles ne savent plus précisément ce qui a amélioré ou détérioré le système.

Sans indicateurs stables, jeux de tests contrôlés et revues régulières, les problèmes sont souvent détectés par les utilisateurs avant de l’être en interne.

6. Arbitrer vitesse vs flexibilité

La flexibilité a un coût réel. Et dans un contexte où les équipes sont sous pression pour livrer rapidement des cas d’usage IA, c’est souvent ce qui disparaît en premier.

Prendre la clé API déjà disponible, utiliser la plateforme déjà sous contrat, construire sur l’orchestrateur connu des équipes : à court terme, ces décisions sont parfaitement rationnelles.

Le problème est que la dette architecturale générée reste invisible au début.

Elle apparaît plus tard, lorsque les prix changent sans alternative crédible. Lorsqu’un agent se comporte différemment en production et qu’aucun mécanisme ne permet de comprendre pourquoi. Ou lorsqu’un nouveau modèle beaucoup plus performant émerge sur le marché, mais que l’architecture existante rend son adoption trop complexe.

Le marché de l’IA évolue aujourd’hui plus vite que les cycles de décision des entreprises.

Une stack construite autour d’un modèle unique ou d’une plateforme rigide vieillit rapidement. À l’inverse, les organisations qui anticipent ces enjeux dès le départ peuvent adopter de nouveaux modèles, négocier avec leurs fournisseurs depuis une position de force et faire évoluer leur architecture au rythme du marché.

Cette capacité d’adaptation devient progressivement un avantage compétitif.

Construire vite sans penser à la portabilité revient finalement à emprunter du temps au futur, sans connaître le coût réel du remboursement.

7. Conclusion

La question n’est plus de savoir si le marché de l’IA va continuer à évoluer. Il évolue déjà, rapidement et de manière imprévisible.

La vraie question est de savoir dans quelle position les entreprises veulent se trouver lorsque ces changements arriveront.

Certaines architectures deviendront progressivement prisonnières de leurs dépendances. D’autres conserveront la capacité de changer de modèle, de plateforme ou de stratégie sans devoir reconstruire l’ensemble de leur système.

La résilience d’une stack IA ne se construit pas une fois les dépendances installées. Elle se construit au moment où les choix sont encore ouverts.