Embedded operators : comment acheter une mise en œuvre de l’IA qui aboutit vraiment

Embedded operators : comment acheter une mise en œuvre de l’IA qui aboutit vraiment

Les plus grandes plateformes d’IA sont toutes arrivées au même modèle de mise en œuvre : placer des ingénieurs au sein du client, pas face à lui. AWS y consacre un milliard de dollars. Pour une entreprise qui n’est pas AWS, la question est plus étroite et plus concrète : comment obtenir le même effet à l’échelle du mid-market, et comment distinguer une véritable mission d’embedded operators d’un conseil qui a simplement changé d’étiquette.

Ce qu’est réellement un embedded operator

Le terme du secteur est forward deployed engineer. Débarrassé de son habillage marketing, il désigne quelqu’un qui écrit du code de production dans votre environnement, raccorde le système à vos données et à vos workflows réels, et reste responsable jusqu’à ce que l’ensemble produise un résultat métier mesurable. Ce qui le distingue n’est ni l’ancienneté ni les compétences. C’est l’endroit où s’arrête sa responsabilité.

La responsabilité d’un consultant s’arrête à la recommandation. Celle d’un éditeur, au produit qui fonctionne conformément au cahier des charges. Celle d’un operator, au moment où votre workflow tourne et où votre équipe sait le faire tourner sans lui. Ce sont trois contrats différents, et acheter le premier en attendant le troisième est la façon la plus courante dont ces missions déçoivent.

Pourquoi ce modèle apparaît maintenant

Deux choses ont changé en même temps. Les modèles sont devenus suffisamment bons pour que la capacité cesse d’être la contrainte, et le travail restant s’est déplacé là où une démo ne peut pas aller : la qualité de vos données, vos circuits d’exception, vos chaînes de validation, les trois systèmes qui n’ont pas d’API. Ce travail vous est propre et ne peut pas être transformé en produit, et c’est pourquoi les plateformes l’ont confié à des personnes.

La lecture honnête, c’est qu’il s’agit d’un aveu sur l’endroit où se trouve réellement la difficulté. Quand des entreprises dont tout le métier est le modèle dépensent un milliard de dollars pour installer des ingénieurs dans les bureaux de leurs clients, c’est que le goulot d’étranglement n’est pas le modèle. Nous avons décrit ce que cela implique pour les programmes internes dans pourquoi les programmes d’innovation s’enlisent sans operators.

Comment l’acheter sans un milliard de dollars

Les entreprises du mid-market ne peuvent pas entretenir une équipe permanente de FDE, et n’en ont pas besoin. Ce qu’il leur faut, c’est ce modèle appliqué à un petit nombre de workflows, avec une véritable passation à la fin. Cinq éléments font la différence entre cela et une coûteuse phase de découverte.

Quand vous ne devriez pas l’acheter

La mise en œuvre intégrée n’est pas le bon achat dans au moins trois situations, et il vaut la peine d’être direct à leur sujet.

Si le processus que vous voulez automatiser n’est pas encore stable, vous allez codifier le désordre à grande vitesse. Stabilisez d’abord le processus : c’est généralement moins coûteux, et cela supprime parfois le besoin d’automatiser. Si les données nécessaires au workflow n’existent pas ou ne sont pas fiables, le premier mois devient un projet de données : cadrez-le comme tel. Et si ce dont vous avez réellement besoin est un outil standard que des milliers d’entreprises utilisent à l’identique, achetez l’outil. Une mission d’operators justifie son coût sur un travail qui vous est propre, pas sur un travail qu’un abonnement résout déjà.

Pour la question plus large de l’articulation entre ce modèle de mise en œuvre et votre organisation interne, notre guide de conception du modèle opérationnel IA explique où doit se situer la responsabilité une fois les premiers workflows en service.

Deux exemples concrets montrent ce que donne ce modèle sur des problèmes qui ne sont pas du tout, en apparence, des problèmes de logiciel : faire émerger le désaccord qu’une réunion de direction dissimule, et évaluer le risque d’acceptabilité locale qui fait échouer les projets d’infrastructure bien avant l’ingénierie. Dans les deux cas, le travail utile a consisté à décider où un modèle avait sa place et, surtout, où il ne l’avait pas.

Sources & références