Nous éditons une plateforme d'IA d'entreprise et nous la déployons chez nos clients. Cette double position, construire l'outil et le mettre en service, nous a appris des choses qu'aucune documentation produit ne raconte.
## La vectorisation s'exécute localement, et ce n'est pas un détail
Quand un document entre dans une base documentaire, il est transformé en index de recherche. Cette transformation peut s'exécuter chez un fournisseur tiers ou sur l'infrastructure qui héberge la plateforme.
Nous avons choisi la seconde option. Conséquence directe : indexer un corpus ne provoque aucun transfert vers un tiers. Seuls la question posée par un utilisateur et les passages retrouvés sont transmis au modèle de langage, et uniquement si ce modèle est externe.
Cette décision a un coût, il faut faire tourner le modèle d'embeddings soi-même, mais elle change la nature de la conversation avec un cabinet d'avocats ou un établissement de santé.
## Le cloisonnement par filtre logique ne tient pas devant un DSI
La manière simple d'isoler les données de plusieurs clients est d'ajouter une condition à chaque requête. Elle fonctionne jusqu'au jour où un développeur oublie la condition.
Nous avons retenu une approche différente : chaque projet dispose de sa propre base vectorielle, physiquement distincte. Il n'y a pas de condition à oublier, parce qu'il n'y a rien à filtrer.
En revanche, et nous le disons à nos clients avant qu'ils ne le découvrent, l'isolation entre organisations sur une infrastructure mutualisée reste applicative, pas cryptographique. Pour une organisation qui exige une séparation cryptographique, la réponse est le déploiement dans sa propre infrastructure.
## Nous avons remplacé un composant que nous avions choisi
Nous utilisions un moteur de workflows visuels tiers. Nous l'avons remplacé par notre propre implémentation.
La raison n'est pas la qualité de l'outil, qui était correcte. C'est que dans notre architecture, un workflow doit pouvoir appeler directement les autres capacités de la plateforme : la recherche documentaire, les connecteurs, les compétences métier, les personas. Un moteur générique traite ces appels comme des intégrations externes. Le nôtre les traite comme des briques de première classe.
Refaire un composant existant est rarement la bonne décision. Elle l'a été ici parce que le point d'intégration était précisément ce qui faisait la valeur.
## Ce qui fait échouer un déploiement n'est presque jamais technique
C'est l'enseignement le plus utile, et le moins spectaculaire.
Les déploiements qui s'arrêtent ne s'arrêtent pas sur un problème de modèle ou de performance. Ils s'arrêtent parce que personne n'a été nommé pour arbitrer, parce que le périmètre s'est étendu sans décision, parce qu'aucun critère de succès n'avait été écrit au départ, ou parce que les utilisateurs n'avaient pas de temps alloué pour s'approprier l'outil.
Nous vérifions désormais sept prérequis avant de nous engager, et nous refusons les projets où plusieurs manquent. Ce n'est pas de la sélection de clients : un projet lancé sans ces conditions échoue, et cet échec coûte plus cher à tout le monde qu'un refus initial.
## Le coût d'ouverture d'un nouveau métier
En juin, nous avons testé la génération d'un environnement métier absent de notre catalogue, décrit en une seule phrase. La plateforme a produit quatre projets, quatre assistants, neuf compétences métier, quatre équipes d'agents, quatre workflows exécutables et cinq connecteurs.
Nous présentons ce résultat pour ce qu'il est : une mesure interne, sur un métier fictif, dont la pertinence métier n'a pas été évaluée par un praticien du secteur. C'est une preuve de faisabilité, pas une preuve de valeur.
Ce qu'elle change concrètement : nous ne partons pas d'une page blanche à chaque nouveau client. L'ossature est générée, et notre travail commence là où il a le plus de valeur, l'ajustement avec les praticiens du métier.
## La vectorisation s'exécute localement, et ce n'est pas un détail
Quand un document entre dans une base documentaire, il est transformé en index de recherche. Cette transformation peut s'exécuter chez un fournisseur tiers ou sur l'infrastructure qui héberge la plateforme.
Nous avons choisi la seconde option. Conséquence directe : indexer un corpus ne provoque aucun transfert vers un tiers. Seuls la question posée par un utilisateur et les passages retrouvés sont transmis au modèle de langage, et uniquement si ce modèle est externe.
Cette décision a un coût, il faut faire tourner le modèle d'embeddings soi-même, mais elle change la nature de la conversation avec un cabinet d'avocats ou un établissement de santé.
## Le cloisonnement par filtre logique ne tient pas devant un DSI
La manière simple d'isoler les données de plusieurs clients est d'ajouter une condition à chaque requête. Elle fonctionne jusqu'au jour où un développeur oublie la condition.
Nous avons retenu une approche différente : chaque projet dispose de sa propre base vectorielle, physiquement distincte. Il n'y a pas de condition à oublier, parce qu'il n'y a rien à filtrer.
En revanche, et nous le disons à nos clients avant qu'ils ne le découvrent, l'isolation entre organisations sur une infrastructure mutualisée reste applicative, pas cryptographique. Pour une organisation qui exige une séparation cryptographique, la réponse est le déploiement dans sa propre infrastructure.
## Nous avons remplacé un composant que nous avions choisi
Nous utilisions un moteur de workflows visuels tiers. Nous l'avons remplacé par notre propre implémentation.
La raison n'est pas la qualité de l'outil, qui était correcte. C'est que dans notre architecture, un workflow doit pouvoir appeler directement les autres capacités de la plateforme : la recherche documentaire, les connecteurs, les compétences métier, les personas. Un moteur générique traite ces appels comme des intégrations externes. Le nôtre les traite comme des briques de première classe.
Refaire un composant existant est rarement la bonne décision. Elle l'a été ici parce que le point d'intégration était précisément ce qui faisait la valeur.
## Ce qui fait échouer un déploiement n'est presque jamais technique
C'est l'enseignement le plus utile, et le moins spectaculaire.
Les déploiements qui s'arrêtent ne s'arrêtent pas sur un problème de modèle ou de performance. Ils s'arrêtent parce que personne n'a été nommé pour arbitrer, parce que le périmètre s'est étendu sans décision, parce qu'aucun critère de succès n'avait été écrit au départ, ou parce que les utilisateurs n'avaient pas de temps alloué pour s'approprier l'outil.
Nous vérifions désormais sept prérequis avant de nous engager, et nous refusons les projets où plusieurs manquent. Ce n'est pas de la sélection de clients : un projet lancé sans ces conditions échoue, et cet échec coûte plus cher à tout le monde qu'un refus initial.
## Le coût d'ouverture d'un nouveau métier
En juin, nous avons testé la génération d'un environnement métier absent de notre catalogue, décrit en une seule phrase. La plateforme a produit quatre projets, quatre assistants, neuf compétences métier, quatre équipes d'agents, quatre workflows exécutables et cinq connecteurs.
Nous présentons ce résultat pour ce qu'il est : une mesure interne, sur un métier fictif, dont la pertinence métier n'a pas été évaluée par un praticien du secteur. C'est une preuve de faisabilité, pas une preuve de valeur.
Ce qu'elle change concrètement : nous ne partons pas d'une page blanche à chaque nouveau client. L'ossature est générée, et notre travail commence là où il a le plus de valeur, l'ajustement avec les praticiens du métier.
