.png)
Il y a un moment que rencontre tout projet IA. Pas à la démonstration. Pas pendant le pilote. En général autour du sixième ou septième mois, quand les réalités de la production remontent et que l'écart entre ce qui a été promis et ce qui est réellement constructible devient indéniable.
Les données ne sont pas industrialisées. Le catalogue produit est stocké dans des formats que le SQL sait interroger mais sur lesquels les agents IA ne savent pas raisonner. Les ontologies — la connaissance structurée de ce qu'est un produit, des questions auxquelles il répond, des attributs qui comptent selon le contexte — n'existent pas encore. L'architecture qui fonctionnait en environnement de démonstration s'effondre sous la complexité réelle du catalogue. La latence explose. La personnalisation à grande échelle exige finalement une infrastructure qui n'était pas prévue.
L'équipe n'annonce pas que le projet échoue. Elle le repriorise. Elle se dit que la technologie n'est pas encore prête.
La technologie est prête. C'est l'infrastructure qui ne l'était pas.
Le vrai calendrier
La plupart des entreprises qui tentent de construire un conseiller IA ou une couche conversationnelle au-dessus de leur catalogue rencontrent la même séquence. Quelques mois de cadrage et de choix d'architecture. Une phase de modélisation des données qui ne cesse de s'étendre à mesure que la complexité réelle apparaît. Un prototype qui finit par fonctionner, sur un sous-ensemble réduit du catalogue. Puis des mois de travail pour le rendre digne de la production — volumes de requêtes réels, cas limites réels, mises à jour de catalogue réelles, intégration multi-sources réelle — qui n'étaient pas dans l'estimation initiale et repoussent sans cesse la mise en ligne.
Au huitième mois, beaucoup d'équipes ont un prototype sophistiqué et une liste croissante de raisons pour lesquelles le déploiement complet est plus loin qu'il n'y paraît.
Kleio livre en 90 jours. Pas en simplifiant le problème, mais en ayant déjà résolu l'infrastructure. Ces 90 jours ne sont pas une mise en ligne d'un seul bloc : nous livrons un premier cas d'usage fonctionnel à vos premiers utilisateurs dès les quatre premières semaines, ce qui crée une boucle de retour immédiate qui nourrit le déploiement plus large.
Trois piliers qui rendent cela possible
Le déploiement en 90 jours n'est pas une promesse adossée à un calendrier agressif. C'est le résultat de trois choix structurels qui suppriment les phases où les projets IA s'enlisent traditionnellement.
Une fondation de données solide. Nous ingérons, unifions et structurons données produit et données client dans des stores dédiés (catalogue produit, prix et disponibilités, graphe de connaissance, recherche documentaire, et d'autres) via notre knowledge engine. Avant qu'un agent IA puisse qualifier un besoin en temps réel sur des milliers de produits, la donnée doit être dans une forme qui le permette : pas des tables SQL, mais des représentations sémantiques, des index vectoriels et des graphes de connaissance — les structures qui permettent à un agent IA de raisonner plutôt que de simplement récupérer. Le travail d'intégration qui prend habituellement des mois se fait en quelques jours, parce que l'architecture cible est pré-construite, pas sur mesure. La latence tient sous les trois secondes pour les requêtes complexes en temps réel, et sous les dix millisecondes pour les schémas de récupération les plus rapides.
Un raisonnement IA en temps réel. Nos agents IA raisonnent sur cette couche de données en quasi temps réel pour mener des conversations et exécuter des parcours, quel que soit le nombre de systèmes ou de sources de données impliqués. Cela suppose de coordonner dynamiquement plusieurs modèles de langage, de router chaque requête vers la bonne combinaison d'agents selon le contexte, d'intégrer des données en direct issues d'API tierces (avis, simulateurs, flux tarifaires, CRM) et de conduire une qualification en plusieurs tours sur un catalogue complexe. Chaque nouvelle source de données enrichit le système sans exiger de changement d'architecture : le déploiement en ligne au troisième mois est aussi celui qui se renforce avec le temps.
Un déploiement prêt à l'échelle. Nous rendons possible le déploiement, le versionnage et la composition de milliers d'agents IA, avec un routage fondé sur la performance intégré d'emblée. Le siège définit le comportement de référence ; chaque entité l'adapte localement. Tout l'historique de configuration est versionné ; n'importe quel environnement peut être restauré instantanément. Une batterie de tests valide et améliore la qualité en continu, par annotation et auto-réglage. Et c'est là que le cercle vertueux s'enclenche : chaque cas d'usage déployé devient une brique pour le suivant. Le premier déploiement demande le plus de travail. Le deuxième hérite de tout ce qui a déjà été validé et n'ajoute que ce qui est réellement nouveau. Au quatrième ou cinquième cas d'usage, le coût marginal a chuté fortement — non parce qu'on a pris des raccourcis, mais parce que l'architecture a été conçue pour cela dès le départ.
Kleio est modulaire et clé en main : à vous de choisir
Ce n'est pas un affrontement entre construire et acheter, ni entre votre stack existante et celle de Kleio.
Kleio est conçu pour être modulaire. Certaines équipes branchent Kleio sur des manques précis de leur architecture — la fondation de données, la couche d'orchestration ou la gestion des configurations — tout en conservant les composants qu'elles ont déjà construits ou dans lesquels elles ont investi. D'autres préfèrent l'approche clé en main : confier à Kleio l'ensemble du système, de l'ingestion des données au déploiement des agents et au pilotage continu de la qualité.
Les deux se défendent. Il ne s'agit pas de tout remplacer, mais de supprimer la phase de découverte de l'infrastructure, qui consomme habituellement des mois quel que soit votre point de départ. Que vous déployiez un pilier ou les trois, les phases qui bloquent d'ordinaire n'existent tout simplement pas, parce qu'elles ont été résolues en amont.
La décision de construire
Certaines équipes tentent d'en construire une partie elles-mêmes. Les premières étapes paraissent gérables. Le modèle de données semble défini. Le premier agent fonctionne. Puis le catalogue grossit, les cas limites se multiplient, la latence grimpe, et l'équipe s'aperçoit qu'elle maintient une infrastructure au lieu de construire un produit.
D'autres achètent des composants — une surcouche de modèle de langage, une couche de recherche, un connecteur MCP — et croient avoir couvert le volet IA. Sans la fondation de données, la logique de qualification, le routage et l'orchestration qui travaillent ensemble, le résultat est exactement celui de la démonstration : convaincant sur les requêtes simples, fragile dès que la complexité réelle apparaît.
Les entreprises qui ont essayé puis reporté n'avaient pas de mauvaises idées. Elles avaient la mauvaise infrastructure pour la complexité rencontrée. Les trois mois que Kleio ne passe pas à découvrir cette infrastructure sont les trois mois qui séparent un système en production d'un prototype sophistiqué.
De la mise en ligne à l'effet cumulatif
Être en ligne en 90 jours est le point de départ, pas la ligne d'arrivée.
Chaque conversation produit des enseignements qui alimentent le modèle de qualification. Chaque nouvelle source de données se connecte sans reconstruction et enrichit immédiatement toutes les recommandations. La composabilité qui a rendu le premier déploiement rapide est la même propriété qui rend les dix cas d'usage suivants bien moins coûteux que le premier.
L'avantage concurrentiel ne tient pas seulement à une mise en ligne plus précoce. Il tient au fait que chaque semaine de données de production creuse l'écart entre un système qui apprend d'interactions réelles et un concurrent encore au stade du prototype. L'architecture est faite pour cela, et le cercle vertueux, une fois lancé, ne cesse d'accélérer.
