Un prototype fonctionnel
Il tourne sur vos données, dans le flux de travail où il vivrait vraiment. Cliquable, pas imaginé.
Tech
La plupart des produits d’IA ne sont pas des agents conversationnels. Ce sont des agents qui achèvent des tâches à travers vos systèmes, des modèles qui notent derrière un simple champ, des outils appelés depuis les logiciels que vos équipes exploitent déjà, des classifieurs au cœur de processus que personne ne regarde.
Quatre choses portent un produit jusqu’à l’usage quotidien : le prototype, la pile qui le soutient, le développement de production, et le rythme qui le tient à jour.

// une requête
tracéequel modèle a répondu · ce qui a été récupéré · ce que cela a coûté
Le premier engagement
« Cela vaut-il la peine d’être construit pour de bon ? »
Un prototype est une preuve, pas une démonstration. Il déroule le chemin idéal, sur des données que nous avons préparées, avec des permissions qui viennent plus tard, face à un seul modèle sans repli.
Il répond à une question, et les deux réponses sont utiles. L’une comme l’autre arrive en deux semaines.
Il tourne sur vos données, dans le flux de travail où il vivrait vraiment. Cliquable, pas imaginé.
Ce qui a marché, ce qui n’a pas marché, et ce que la preuve dit d’une construction pour de bon.
Détaillé au regard des neuf décisions ci-dessous, pour que l’engagement suivant soit chiffré avant que vous le preniez.
Deux objets différents
C’est une tout autre chose, et voilà toute l’explication du pourquoi : l’un prend deux semaines, l’autre trois mois. Basculez de l’un à l’autre et regardez ce qui doit changer.
Six choses changent, et chacune relève d’une ingénierie que le prototype avait le droit de sauter.
La pile
Tout produit d’IA est fait de ces neuf couches, que quelqu’un les ait choisies délibérément ou non. Nous les choisissons avec vous, et nous en écrivons la raison.
Quatre méritent d’être tranchées avec soin, parce que les défaire plus tard coûte de l’argent réel. Les autres peuvent changer dès que la preuve change.
// neuf couches, un seul système. La plaque éclairée est celle que vous lisez.
Notre choix par défautSans interface ou intégrée. La conversation là où la tâche n’a pas de fin définie.
Une fenêtre de conversation est la bonne réponse bien moins souvent qu’on ne la prescrit. La plupart des tâches ont un début et une fin, et leur place est dans les logiciels que les gens ont déjà ouverts.
Notre choix par défautUne colonne vertébrale déterministe, le modèle appelé à des points choisis.
Moins cher à exploiter, plus simple à déboguer, prévisible en charge. L’autonomie reste réservée aux étapes dont le chemin ne peut réellement pas se connaître à l’avance.
Notre choix par défautPoints de reprise LangGraph en deçà d’une heure, Temporal au-delà.
Tout traitement assez long pour être interrompu doit survivre à l’interruption. Le seuil se situe autour d’une heure de travail réel.
Notre choix par défautRecherche hybride et reclasseur avant toute solution exotique.
La récupération décide de la qualité des réponses plus que le modèle. Une recherche hybride avec reclasseur en règle l’essentiel sans lancer un projet de recherche.
Coûteux à défaire : le modèle de plongements.
Notre choix par défautpgvector sous dix millions de vecteurs, Qdrant ou Weaviate au-dessus.
Une base dédiée mérite sa place quand l’échelle, le filtrage par métadonnées ou l’isolement des clients l’exigent. En deçà, c’est un système de plus à exploiter.
Coûteux à défaire : l’endroit où résident les données.
Notre choix par défautToujours une passerelle. C’est elle qui rend le routage réel.
Une seule porte de sortie transforme le routage, les plafonds de budget, le repli entre fournisseurs et la journalisation par appel : d’intentions, ils deviennent des mécanismes.
Coûteux à défaire : passerelle ou pas de passerelle.
Notre choix par défautMCP, avec authentification et permissions par serveur en amont.
Un protocole partagé fait d’un nouvel outil un changement de configuration plutôt qu’un développement. La couche de permissions en amont n’est pas facultative.
Notre choix par défautUne suite qui conditionne les déploiements, comme des tests ordinaires.
Une qualité contrôlée à l’œil dérive en silence. Une suite bâtie sur des cas réels tirés de votre travail attrape la régression avant la mise en ligne.
Notre choix par défautConventions OpenTelemetry GenAI, dans la supervision que vous exploitez déjà.
Des conventions ouvertes font atterrir les traces dans les outils que votre équipe surveille déjà, au lieu d’un second tableau de bord que personne n’ouvre.
Coûteux à défaire : la journalisation ou non des appels d’outils.
Pourquoi ces choix par défaut
Les flux coûtent moins cher, sont plus prévisibles et plus simples à déboguer que les agents. L’autonomie mérite sa place là où le nombre d’étapes ne peut réellement pas se connaître à l’avance.
Les flux offrent prévisibilité et constance pour des tâches bien définies, tandis que les agents sont le meilleur choix lorsqu’il faut de la souplesse et une décision pilotée par le modèle, à grande échelle.
Anthropic, Building Effective AI Agents, décembre 2024
Elle décide de la qualité des réponses plus que le modèle. Une recherche hybride avec reclasseur règle à elle seule l’essentiel du travail de récupération. Une base vectorielle dédiée mérite sa place quand l’échelle, le filtrage par métadonnées ou l’isolement des clients l’exigent.
Un modèle rapide et bon marché pour la classification et l’extraction, un modèle de pointe pour le raisonnement qui l’exige, dans le même système. C’est la passerelle qui rend cela possible.
Le développement
« Qu’est-ce qui lui fait survivre à de vrais utilisateurs ? »
Le prototype a mérité la décision. Ce développement en fait un système que votre organisation exploite chaque jour, sur les enregistrements tels qu’ils arrivent vraiment.
Les vrais enregistrements remplacent l’échantillon propre. Champs manquants, doublons, la convention de nommage vieille de douze ans que personne n’a documentée.
Filtrer par permission avant la récupération, pour que le système n’atteigne jamais que ce que l’utilisateur a le droit de voir.
Validation par schéma sur tout ce qui suit, avec un comportement défini quand une réponse en sort.
Accès restreint par outil, et confirmation humaine sur les actions à conséquence.
Des plafonds par utilisateur et par charge, dimensionnés sur les volumes réels de production, pas sur ceux d’un pilote.
Reprises, repli entre fournisseurs, et un retour arrière réellement testé.
Par vagues, une mesure à chacune, pour que l’adoption s’observe au lieu de se présumer.
// ce que vous obtenez
« Qui le tient à jour ? »
Les modèles progressent, les prix baissent, les fournisseurs livrent de nouvelles versions. Réévaluer n’est pas de l’entretien : c’est le travail de performance le moins cher qui soit, et il s’amortit d’ordinaire de lui-même.
Changer de modèle de plongements suppose de réindexer le corpus. Nous le prévoyons dès le premier jour, pour que cela reste une opération planifiée plutôt qu’une crise.
Au mois, dimensionné au système : un interlocuteur senior nommé, un rythme de réévaluation, un backlog transparent, et un modèle de coûts confronté à la dépense réelle. Tout est documenté pour une passation à tout moment.
FAQ
Deux objets différents. Le prototype tourne sur des données que nous avons préparées, pour des utilisateurs présents, un seul modèle, sans repli. La production tourne sur les données telles qu’elles arrivent, pour des utilisateurs absents. Le second délai va à la qualité de récupération, aux habilitations, à l’évaluation, à la gestion des pannes et à l’intégration.
Cela dépend du volume et du routage, et nous le modélisons pendant le prototype plutôt que de l’estimer après coup. Le prototype rend compte du coût par exécution sur vos vraies données, ce qui s’extrapole aux volumes de production avec une précision raisonnable. Les plafonds de budget par utilisateur et par charge sont fixés avant le lancement.
Oui, après une évaluation. Nous regardons comment la récupération est évaluée, où les permissions s’appliquent et ce qui est tracé aujourd’hui, puis nous vous donnons une trajectoire chiffrée, options côte à côte.
Non. Nous bâtissons sur ce que vous exploitez déjà. Nous donnons un avis réfléchi sur les quatre décisions coûteuses à défaire : l’endroit où résident les données, le modèle de plongements, la passerelle, la journalisation des outils.
En général plusieurs au sein du même système, routés par tâche. L’évaluation comparative relève du pilier IA ; ce pilier-ci en met le résultat en œuvre.
Les deux, et le choix se fait étape par étape plutôt que projet par projet. La plupart des systèmes que nous livrons sont un flux codé qui appelle un modèle à des points précis, le comportement autonome étant réservé aux étapes dont le chemin ne peut réellement pas se connaître à l’avance. Ce mélange coûte moins cher à exploiter et se raisonne plus facilement quand il faut changer quelque chose.
Tant mieux, cela raccourcit le développement. La plupart de ces couches reposent sur une infrastructure que vous exploitez déjà, et la récupération en particulier fonctionne mieux au plus près des systèmes où vos données résident. Nous partons de votre pile et ajoutons ce que le cas d’usage exige.
Oui. Résidence et souveraineté sont deux questions distinctes, et nous répondons aux deux dès la conception. La résidence, c’est l’endroit où la donnée se trouve physiquement. La souveraineté, c’est la loi qui l’atteint, laquelle dépend de qui exploite l’infrastructure plutôt que de l’emplacement du bâtiment. Les deux figurent au document d’architecture avant que le développement commence.
Une suite d’évaluation tourne en intégration continue sur un jeu de cas réels tirés de votre travail, si bien qu’un changement qui déplace la qualité se voit avant la mise en ligne. En production, la traçabilité montre le parcours complet de chaque requête : quel modèle a répondu, ce qui a été récupéré, quels outils ont été appelés, ce que cela a coûté. Votre équipe a la même vue que nous.
C’est l’intention même. Le code source, la documentation et le registre des décisions d’architecture vous appartiennent d’un bout à l’autre. Là où votre équipe veut posséder une couche dès le départ, nous la construisons avec elle plutôt que de la transmettre plus tard.
Oui. Le code source, la documentation et les données vous appartiennent.
Réalisations liées
Trois développements partis en production et qui y sont restés : une intégration ERP derrière une validation humaine, deux API publicitaires réunies dans un seul espace de travail, et une chaîne de devis dont les commerciaux se servent vraiment.

Achats et chaîne d’approvisionnement
Les écarts apparaissaient à la réception, bien trop tard pour agir. L’extraction, le rapprochement à trois voies et une file d’exceptions ont ramené la découverte au stade de la confirmation.
Extraction manuscrite abandonnéeLire le cas→
Génération de demande
Deux personnes pilotaient les deux régies en plus du reste. Un espace de campagne rédige, teste et ajuste désormais. Aucune des deux interfaces publicitaires ne s’ouvre en exploitation normale.
Les deux régies mises de côtéLire le cas→
Vente et tarification
La logique tarifaire vivait dans la tête de trois personnes. L’écrire a constitué l’essentiel du projet. Les commerciaux vérifient et envoient au lieu d’assembler.
La logique tarifaire, écriteLire le cas→Parlons-en
Un échange avec l’équipe senior sur vos marchés, vos données, et l’endroit où l’IA vous rapporterait vraiment. Sans diapositives, sans engagement, et si la réponse honnête est que l’IA n’est pas votre prochaine étape, vous l’entendrez aussi.