Un partenaire de mise en œuvre de l’IA
qui vend du jugement, pas des effectifs.
Tous les prestataires d’ingénierie intégrée proposent la même chose : des ingénieurs seniors dans votre dépôt de code, dès la semaine prochaine. C’est répondre par des effectifs à un problème de jugement. Nous travaillons aux côtés de celles et ceux qui font le travail pour décider quelles parties doivent devenir un modèle, lesquelles doivent devenir du code classique, et lesquelles doivent rester entre les mains d’une personne. En général, la majeure partie du système ne devrait pas être de l’IA.
- Cinq livrables nommés, pas des effectifs
- Construit sur votre ERP. Jamais de migration.
- La cartographie, payante, vient d’abord : le devis de développement est un constat, pas une estimation au jugé
Sprint de cartographie de cinq jours · Premier workflow en production en 6 semaines · Europe
Une équipe d’ingénieurs
Des ingénieurs seniors intégrés à votre dépôt de code. Démarrage sous sept jours. Quatre à huit semaines pour livrer. Facturés par ingénieur et par mois. C’est toujours vous qui décidez quoi construire, et vous portez toujours le risque de construire la mauvaise chose.
La décision sur la place de l’IA
Nous parcourons le processus réel avec celles et ceux qui le pilotent, nous identifions les exceptions que personne n’a documentées, et nous traçons la frontière entre ce qui doit relever d’un modèle, ce qui doit relever du code et ce qui doit rester humain. Ensuite, nous construisons la petite partie qui doit l’être.
Les plateformes l’ont déjà reconnu.
Le modèle du forward deployed engineer est né chez Palantir, et les laboratoires d’IA l’ont adopté : OpenAI comme Anthropic disposent d’équipes de forward deployed engineering. En juin 2026, AWS a annoncé un investissement de 1 milliard de dollars pour intégrer des forward deployed engineers spécialisés en IA auprès de ses clients, en décrivant des milliers d’experts travaillant dans les environnements de ces clients, avec l’autonomie de ces derniers comme condition de sortie.
Quand les entreprises dont tout le métier est le modèle dépensent un milliard de dollars pour intégrer des ingénieurs aux équipes de leurs clients, c’est que le goulot d’étranglement n’est pas le modèle. Ce sont vos données, vos cas d’exception, vos circuits de validation, et les trois systèmes qui n’ont pas d’API. Rien de tout cela n’apparaît dans une démo, et rien de tout cela ne figure dans la documentation de vos processus.
Sources : AWS, « AWS invests $1 billion to embed AI forward deployed engineers with customers » (2026) ; Databricks, « Forward Deployed Engineering ».
Comment acheter cela sans un milliard de dollars (en anglais) →Cinq livrables, chacun identifiable.
Une équipe d’ingénieurs ne s’inspecte pas. Un document, si. Chacun de ces livrables a une définition, un responsable et une date de livraison : c’est ce qui rend la mission auditable, au lieu de la faire reposer sur la confiance.
Consultez-en deux, caviardés, issus d’une mission réelle (en anglais) →Le Registre des exceptions
Un relevé écrit de chaque écart réel par rapport à votre processus documenté. Pour chacun : sa fréquence, la personne qui l’absorbe aujourd’hui, et l’endroit où se trouve réellement la logique de routage. C’est cette dernière colonne qui compte, car la réponse n’est presque jamais « la documentation ». Elle est dans la tête d’une seule personne, et depuis onze ans.
La seule façon de le produire est d’observer le processus réel, exception par exception, avec celles et ceux qui les traitent, et de continuer à demander pourquoi jusqu’à ce que la règle apparaisse. Une équipe qui travaille à partir de votre dépôt de code et d’un point d’avancement hebdomadaire ne fait pas cela. L’information n’est pas dans le dépôt, et personne ne la livre spontanément en réunion, parce que personne ne pense à mentionner ce qu’il a toujours su. Ce n’est pas une lacune de documentation. C’est à cela que ressemble l’expertise, vue de l’extérieur.
- Chaque écart, avec sa fréquence observée plutôt qu’estimée
- La personne qui l’absorbe aujourd’hui, nommément
- L’endroit où se trouve la règle de décision, et si elle peut être formalisée par écrit
- Les exceptions qui doivent rester humaines, et pourquoi
La Carte des frontières IA
Votre workflow, annoté étape par étape : code déterministe, véritable jugement d’un modèle ou validation humaine. Le chiffre clé est le ratio de déterminisme, et le constat clé est presque toujours le même : la majeure partie du système ne devrait pas être de l’IA.
Dans le workflow de traitement des commandes d’un industriel européen que nous avons cartographié, trois étapes sur onze nécessitaient réellement un modèle. Les huit autres relevaient de l’extraction de données, de la recherche dans des référentiels, de la validation et du routage — un travail que le logiciel classique fait à moindre coût, plus vite, et avec une réponse que vous pourrez reproduire à l’identique demain. (Source : données de mission SUPALABS.)
C’est pourquoi un prestataire « AI-first » n’est pas le bon type de fournisseur pour ce problème. Si la réponse à la question « quelle part de ce système doit être de l’IA ? » détermine le montant de la facture, vous n’obtiendrez pas de réponse honnête.
La Suite d’évaluation et le rapport mensuel de précision
Un jeu de données de référence (golden dataset) constitué à partir de vos propres cas historiques, des taux de réussite par étape mesurés sur ce jeu, et des alertes lorsqu’une étape régresse. La suite fait l’objet d’une ligne distincte du devis, jamais intégrée au développement, car une capacité invisible sur une facture est une capacité que l’on supprime discrètement dès que le calendrier se resserre.
- Un jeu de données de référence construit à partir de vos cas réels, y compris les plus épineux
- Des taux de réussite par étape, et non un score global pour tout le système
- Des alertes de régression lorsque le comportement du modèle dérive après une mise à jour du fournisseur
- Un rapport mensuel rédigé pour la personne qui doit valider le système
C’est aussi la raison honnête pour laquelle la relation se poursuit après le développement. Les fournisseurs de modèles modifient leur comportement sans vous demander votre avis. Quelqu’un doit s’en apercevoir.
Le Journal des décisions
Chaque action d’agent, ses données d’entrée, son niveau de confiance et la personne qui l’a validée, présentés dans une interface qu’un responsable conformité peut ouvrir sans demander l’aide d’un ingénieur.
C’est de l’ingénierie ordinaire, et nous ne prétendrons pas le contraire. La différence ne tient pas à son ingéniosité, mais au fait que la plupart des fournisseurs s’en dispensent, et qu’un système qui en est dépourvu n’obtient pas l’autorisation d’approcher la production dans un environnement réglementé ou audité. C’est tout l’argument pour le construire : c’est ce qui autorise le système à fonctionner.
L’Engagement ERP
Nous construisons sur votre ERP existant, sans le remplacer. Nous ne proposons pas de remplacer vos systèmes. Nous n’exigeons aucune migration. C’est un engagement pris par écrit au démarrage de la mission, pas une préférence que l’on abandonne dès qu’elle devient gênante.
Un programme de refonte de plateforme est le plus grand risque de carrière qu’un responsable des opérations ou de l’informatique puisse prendre, et ce n’est presque jamais ce que le problème exige réellement. Le workflow est lent à cause des exceptions, des passages de relais et des validations — pas à cause de la base de données qui se trouve en dessous. Changer de base de données n’y change rien, et il faut deux ans pour s’en rendre compte.
L’engagement a un second volet : vous arrêtez le service, vous gardez le système. Ce que nous construisons tourne dans vos comptes, sur les logiciels dont vous disposez déjà, et est documenté pour votre équipe dès la première semaine, car la passation est un livrable de la phase de Développement et non une faveur accordée à la fin. Si vous arrêtez la phase d’Exploitation, le workflow continue de tourner et le jeu de données de référence reste chez vous.
Pour les programmes à l’échelle de l’organisation, voir l’AI Efficiency Programme (en anglais) →Quatre étapes. Vous pouvez vous arrêter après chacune.
Trois niveaux, définis par type de tâche, avec des seuils fixés par vous.
Chaque tâche automatisée s’exécute à l’un des trois niveaux d’autorité. Le niveau est défini par type de tâche et non par système : un même workflow peut ainsi préparer un brouillon à une étape, attendre une validation à une autre et agir seul à une troisième. Une tâche ne monte d’un niveau que lorsque la Suite d’évaluation atteint le taux de réussite que vous avez fixé comme seuil, et elle redescend dès que le rapport mensuel de précision signale une régression.
Aucune promotion ne se fait sur notre seule parole. Les seuils sont les vôtres, le rapport qui les vérifie est une ligne distincte du devis, et le Journal des décisions montre chaque action menée à chaque niveau.
La méthode complète : cinq livrables, trois niveaux, quatre étapes (en anglais) →Quand vous ne devriez pas acheter cette prestation.
Dans trois situations, une mission d’embedded operators n’est pas le bon achat, et il est moins coûteux pour nous deux de l’établir lors d’un appel de trente minutes qu’au deuxième mois.
Si vous êtes dans l’une de ces trois situations, nous vous le dirons lors de l’appel de qualification plutôt qu’après la facture. Cela nous coûte une affaire et vous épargne un programme.
Questions fréquentes
Trente minutes pour savoir s’il y a quelque chose qui mérite d’être cartographié.
L’appel est gratuit, et nous vous dirons si la réponse est non. Venez avec un workflow qui vous agace.