Il y a un peu plus d'un an, j'ai passé une heure en appel avec quelqu'un qui a pratiqué le déploiement sur site pendant une décennie dans l'entreprise qui a inventé le terme. Au cours des 12 derniers mois, j'ai collaboré sous différentes formes avec des personnes qui construisaient leurs moteurs de déploiement sur site. J'ai toujours l'impression qu'aucun contenu ne rend justice à tout ce que le déploiement sur site implique.
Quand j'ai parlé à mon ami, je lui ai demandé comment fonctionnait le fameux processus de découverte. La réponse était presque embarrassante de simplicité, du moins à première vue, si l'on ne regarde que la surface. Tu arrives en avion. Tu passes deux jours à rencontrer tous ceux qui touchent au problème. Le responsable ERP te donne un cours théorique sur les bons de commande. Ensuite, ils t'emmènent sur le terrain pour que tu voies ce que la théorie omet. Puis tu passes trois semaines à leur poser une question par jour pendant que tu wires les données. J'ai demandé s'il y avait une formule. Il a dit que la formule, c'était de passer le plus de temps possible avec les personnes qui savent. Dix ans plus tard, cette partie n'a jamais changé.
Cependant, cela peut être trompeur si l'on ne creuse pas plus loin. Oui, ils passent beaucoup de temps avec les clients. Cependant, les bons moteurs de déploiement sur site construisent le modèle à l'avance. Les grands ingénieurs et stratèges de déploiement reconnaissent qu'ils ne comprendront pas tout, mais ils sont très rapides à construire des choses et à itérer avec les clients. Le premier workflow est l'objectif immédiat. Les ontologies sont utilisées comme un moyen d'étendre progressivement cet outil vers un système d'exploitation. Là où les bons moteurs de déploiement sur site excellent, c'est dans le fait qu'une grande partie du contexte provient de l'équipe, des experts métier, et ils assemblent tout cela dans une large mesure avant même de rencontrer le client pour la première fois. Cette partie s'est améliorée avec le temps et est la véritable raison pour laquelle certains moteurs cumulent et d'autres non.
J'ai immédiatement eu deux pensées. Vous les avez probablement si vous n'avez pas prêté attention à ce qu'est un bon déploiement sur site, alors je vous encourage à lire la suite.
Ma première pensée a été : que se passe-t-il quand vous n'avez aucune idée des workflows du client ? Vous commenceriez par beaucoup d'entretiens, non ? Mon ami a dit non parce que personne n'aime être interviewé, mais il a raconté une histoire. Son équipe a un jour construit un moteur de routage pour une entreprise de logistique où les répartiteurs assignaient quotidiennement des tickets aux chauffeurs ou aux itinéraires en se fiant à leur jugement manuel et en regardant les cartes, les distances, l'emplacement des décharges et d'autres contraintes opérationnelles. Mon ami a construit un outil qui donnait des recommandations aux répartiteurs, mais le premier problème était que les répartiteurs rejetaient souvent la recommandation en se basant sur leur intuition et ne pouvaient pas expliquer clairement pourquoi. Pour gérer cela, son équipe a dû exposer toutes les permutations d'assignation possibles, puis ils ont utilisé cette visibilité pour comparer les décisions humaines aux résultats simulés. C'était la première fois que quelqu'un cartographiait toutes les permutations sur un écran et donc la première fois que les gens avaient un moment pour réfléchir à savoir si la décision qu'ils prenaient basée sur l'intuition était soutenue par des données à grande échelle. Cela a permis à l'équipe de l'entreprise de logistique d'auditer le workflow lui-même, de comprendre si la logique du processus était réellement correcte et d'affiner le jumeau numérique pour qu'il corresponde mieux à la façon dont l'entreprise fonctionnait en pratique. Ils ont également apprécié le processus car il n'a jamais ressenti comme un entretien, mais leur a plutôt permis, pour la première fois, de voir toutes les pièces du puzzle sur un seul tableau.
Ma seconde pensée a été : comment l'ajout d'agents change-t-il tout le processus aujourd'hui par rapport à ce qu'il était il y a quelques années ? La réponse de mon ami a été que cela implique simplement que nous pouvons développer beaucoup plus rapidement en utilisant des agents et avoir plus de contexte au niveau de la connaissance tribale, mais ce n'est qu'une partie du puzzle. Il a dit que la sauce magique dans leur modèle de déploiement sur site en ce qui concerne ces pilotes n'a rien de digne d'Einstein. Dans certains cas, même maintenant, pendant qu'ils font des pilotes, ils se contentent d'écouter les étapes et les résultats, de faire du verb-mapping et de donner au client une équipe de cinq personnes pour être ses ingénieurs dédiés. Ces ingénieurs codifient tout, puis ils peuvent disparaître et le client peut continuer à utiliser la solution. Les agents aident en ce sens qu'ils accélèrent et approfondissent le processus de codification en facilitant l'incorporation de plus de contexte et de connaissances tribales provenant des systèmes du client. Les agents sont devenus un moyen d'aller au-delà du simple retour d'information direct des utilisateurs et d'extraire plutôt le contexte historique et opérationnel, comme les e-mails, les changements de processus de vente, les changements de statut dans des systèmes comme Salesforce, et d'autres traces de la façon dont l'organisation a fonctionné au fil du temps. Cela permet de modéliser les workflows des clients de manière plus riche, de relier des sources de connaissances fragmentées et de construire des systèmes qui non seulement représentent l'entreprise via un jumeau numérique, mais aident également à automatiser ou à soutenir les décisions que les gens prennent actuellement manuellement.
J'ai quelques paragraphes de la transcription de mon appel avec lui.
Donc, la façon dont nous commençons, c'est que nous nous concentrons toujours sur la rapidité à créer de la valeur. Nous ne suivons pas toujours une approche procédurale du genre, d'accord, commençons par l'ontologie. Ensuite, construisons l'application par-dessus. Ensuite, allons voir l'utilisateur. Non. Par certains aspects, nous la suivons, mais par d'autres, nous demandons simplement au client : quelle est la plus grande valeur ajoutée que nous pouvons construire pour vous, ou quel est le plus grand impact que nous pouvons vous apporter maintenant ? Expliquez-nous le problème dans votre entreprise et maintenant le problème que vous pensez que nous pouvons résoudre.
Une fois que le client partage, nous allons un peu à la planche à dessin et nous disons : d'accord, découpons une version un de l'ontologie, construisons une version un de l'application également en l'espace d'une semaine et testons-la. C'est donc très similaire à la façon dont on construirait une startup. Souvent, nous constatons qu'ils peuvent avoir une idée d'un cas d'usage, mais pendant qu'ils parlent, nous découvrons un autre cas d'usage potentiel que nous pouvons résoudre. Et nous allons simplement le construire, même s'ils pensaient avoir besoin d'autre chose. En fin de compte, nous essayons de nous ajuster pour résoudre le plus gros problème qu'ils ont besoin de résoudre.
Nous allons construire quelque chose rapidement pour cela et créer cinq objets dans l'ontologie. Si nous faisons quelque chose lié au système ERP, qui peut être assez complexe, même après avoir fait les intégrations, nous contactons cet expert ERP, quelques fois pour une session de type "jam session" d'une heure ou une réunion ponctuelle d'une demi-heure pendant la semaine. Et une fois que nous avons fait nos preuves là-bas, nous cherchons ce deuxième, troisième, quatrième cas d'usage, au point de pouvoir construire un système d'exploitation d'entreprise pour toute leur société.
Nous faisons généralement cela sous forme de visite sur site. Nous arrivons en avion, nous disons d'accord, donnez-nous deux jours. Nous rencontrons les parties prenantes, soit tous ensemble si possible, soit en tête-à-tête. Dans de nombreux cas, quand les gens sont occupés, nous nous asseyons simplement à côté d'eux et essayons de comprendre leur processus de vente ou leur type d'interaction client. Nous essayons de comprendre de leur point de vue ce qui se passe et nous n'essayons pas de réduire le temps passé avec le client. En fait, nous continuons à y investir davantage, et c'est quelque chose qui n'a jamais changé en 10 ans. Parfois, nous passons des semaines entières avec les clients. Nous n'avons jamais essayé de nous en éloigner et de rendre notre plateforme entièrement automatisée d'une manière ou d'une autre en ce qui concerne la découverte.
Une idée centrale de la discussion était que la codification se fait par itération, et non par une documentation lourde. L'équipe construit un "jumeau numérique" de l'entreprise directement dans le code, en utilisant les intégrations de données, le contexte opérationnel et les apports des experts métier pour représenter la façon dont l'organisation fonctionne en pratique. Mais ce modèle de données seul ne suffit pas. La couche la plus difficile et la plus précieuse est la logique métier - la compréhension de là où l'intervention compte, quelles actions devraient être recommandées et comment les opérateurs expérimentés prennent réellement leurs décisions. Tout cela ne consiste pas seulement à exposer des informations, mais à aider les utilisateurs à évaluer les compromis, à valider les workflows et, finalement, à intégrer l'aide à la décision dans le produit lui-même.
Le reste de ma conversation est allé plus loin dans la façon dont ce travail ne dépend pas du fait d'avoir des experts du domaine profondément intégrés dès le départ. L'attente est que les ingénieurs déployés sur site puissent entrer dans des environnements inconnus, apprendre rapidement et gagner en crédibilité en produisant des systèmes utiles rapidement. Les premiers engagements commencent souvent par un court boot camp, soutenu par des prototypes préconstruits et des données d'exemple, conçus pour démontrer rapidement la valeur et gagner le droit à un déploiement plus profond. À partir de là, la relation peut s'étendre d'un seul cas d'usage à un système d'exploitation plus large pour le client, avec l'objectif à long terme de codifier les workflows si efficacement que l'équipe peut éventuellement prendre du recul pendant que le client continue d'utiliser la solution.
C'est un playbook très pertinent pour une nouvelle entreprise en cours de construction. C'est ça, le déploiement sur site. Tout le reste n'est peut-être que décoration.
La loi de l'effet cumulatif
Le déploiement sur site est coûteux, lent à se manifester dans la marge brute et difficile à planifier de manière ordonnée. Les fondateurs le ressentent et commencent à se demander si l'effort vaut la percée. Finalement, un leader le dit à voix haute : nous mettons 2 fois plus d'efforts et obtenons 2 fois plus de résultats.
Cette phrase est un signal d'alarme pour certaines industries si elle implique que le déploiement sur site n'est pas le bon modèle. Je comprends l'impatience d'un fondateur, en ayant été un moi-même, mais il y a une frontière ténue entre la naïveté et l'impatience. Pour les entreprises qui fonctionnent mieux avec un moteur de déploiement sur site, quiconque fait ce calcul en multiplication n'a pas compris le job. Si 2 fois plus d'efforts achètent 2 fois plus de résultats, vous avez embauché des consultants et les avez habillés en ingénieurs. Vous ajouterez des effectifs en parallèle des revenus pour toujours, vos marges ne s'échapperont jamais, et le nom honnête pour ce que vous avez construit est une agence de staffing qui livre du code ou fournit du support. Les personnes qui ne sont pas claires sur ce qu'elles construisent finissent presque toujours avec des résultats médiocres, et cette confusion particulière joue contre vous.
Le déploiement sur site n'a de sens que si le calcul s'infléchit. Le déploiement numéro un a le droit d'être moche, artisanal, économiquement indéfendable. Son job est d'enseigner. Le déploiement numéro deux doit être moins cher car le déploiement un a laissé derrière lui un template, une intégration, un pattern documenté, un morceau de plateforme. Au déploiement numéro dix, la plupart de ce que la première équipe faisait à la main devrait se faire par configuration, et les humains devraient être un niveau au-dessus, résolvant des problèmes qui n'existaient pas il y a un an, même aux yeux du client. La distance entre ces deux chiffres au mois 1 et au mois n est un effet cumulatif, et cette courbe est la chose réelle que vous achetez quand vous financez une équipe de déploiement sur site. L'effet cumulatif est tout l'intérêt. Se qualifier de déploiement sur site sans un moteur qui cumule est tout simplement stupide.
Un ingénieur logiciel et un ingénieur déployé sur site diffèrent principalement par le temps qu'un ingénieur logiciel passe à écrire du code qui maintient des choses, supporte des choses ou construit des choses sur la roadmap, par rapport à ce que l'ingénieur déployé sur site passe à découvrir des choses qui ne sont souvent pas sur la roadmap mais qui débloquent de la valeur client, à les déployer et à les transmettre au produit lorsque le pattern commence à se répéter chez les clients.
Le mot que tout le monde utilise et que presque personne ne maîtrise
L'idée a une origine spécifique. Il y a deux décennies, un fondateur a demandé pourquoi les grands restaurants français sont grands, et a conclu que c'était le serveur. Dans un grand restaurant, le serveur fait partie de la cuisine, donc quand il recommande quelque chose, c'est la cuisine qui parle. Palantir a construit la version ingénierie de cela et a donné au rôle un nom militaire, car ses clients étaient militaires. Le nom a donné un statut mérité au travail de terrain, et à juste titre. Cela payait si bien que vingt ans plus tard, tout le monde veut le nom, mais je ne suis pas sûr que beaucoup de gens comprennent le travail.
D'une certaine manière, une équipe de déploiement sur site doit faire ce qu'un fondateur doit faire dans la phase 0-1. Vous découvrez souvent ce que vous pourriez livrer qui non seulement améliorerait une métrique de vanité, mais aiderait vraiment votre client à développer son activité. Voici un autre exemple concret tiré de la conversation de mon ami. Son équipe a été embauchée par un fabricant de bornes de recharge pour véhicules électriques qui voulait augmenter sa production d'environ 10 fois. C'était le brief. Pouvez-vous deviner le résultat ? Parce que ce n'était certainement pas un deck de stratégie. L'objectif de l'entreprise était simple en surface : augmenter la production de bornes de recharge de 10 fois. Ce que l'équipe de déploiement sur site a réellement fait, c'est se rendre sur place et apprendre le fonctionnement de l'entreprise à plusieurs niveaux. Ils ont passé du temps avec le responsable ERP pour comprendre le système d'enregistrement, les bons de commande, les ordres de fabrication, l'offre et la demande. Ils sont ensuite allés sur le terrain pour voir comment la production se déroulait réellement en pratique. En même temps, ils ont parlé aux dirigeants pour comprendre la version stratégique du problème, car ce que les opérateurs de première ligne disent être faux ou urgent ne correspond pas toujours parfaitement à ce que la direction voit comme la contrainte la plus importante. Le travail, alors, n'était pas de construire directement une nouvelle ligne de production, du moins pas d'après ce qui a été dit lors de la réunion. C'était de construire un jumeau numérique de l'opération, puis d'identifier où le logiciel pouvait intervenir dans le workflow, par exemple, autour de problèmes comme les pénuries de pièces critiques, le timing des bons de commande, le stock de sécurité et d'autres décisions opérationnelles. Le résultat décrit était un système capable de détecter les risques plus tôt et de recommander des actions, plutôt qu'un changement physique dans la fabrication elle-même. J'espère que cela explique ce que je veux dire quand je dis que les ex-fondateurs peuvent être des professionnels exceptionnels du déploiement sur site.
Regardez sous l'expérience professionnelle d'aujourd'hui (pas les descriptions) et vous trouverez des ingénieurs qui écrivent du code de production dans les systèmes d'un client et qui sont propriétaires de ce qui se passe après le lancement, y compris le support. Le reste sont des ingénieurs commerciaux avec une meilleure carte de visite, jugés sur la démo, plus une queue de rôles d'automatisation internes qui ont emprunté le mot parce que c'est à la mode. Les confusions adjacentes sur ce qu'est le déploiement sur site sont pires. Faire appel à un réseau d'experts via une centaine d'entretiens de domaine est de la recherche, mais ce n'est pas du déploiement sur site. Quand un fonds de private equity regroupe des entreprises et envoie une équipe de transformation, c'est utile, parfois brillant, mais pas nécessairement du déploiement sur site. Je dis cela parce que personne dans ces deux mouvements n'est propriétaire de ce que j'appelle la "clôture du travail" (work-closure).
La clôture du travail est l'unité dans laquelle toute cette discipline est libellée. Pas une fonctionnalité livrée, pas un ticket résolu. Un morceau du travail du client, porté depuis l'inquiétude persistante jusqu'à quelque chose dont personne ne se soucie plus. La signature du contrat est la frontière entre les professions qui sont confondues ici. Un ingénieur commercial travaille jusqu'à elle. Une équipe de déploiement sur site commence à partir d'elle, car convenir que quelque chose devrait fonctionner n'est pas la même chose que cela fonctionne. Si la personne porte un quota, vous regardez de la vente. Si la personne est encore dans les logs du client trois mois après le lancement, vous regardez du déploiement sur site. Une entreprise qui vend un produit marketing enverra des ingénieurs commerciaux pour faire signer le contrat et pour déployer et configurer des choses. Un véritable FDE pourrait arriver à la conclusion qu'aucun des workflows supportés par le produit n'aidera le client en question et que quelque chose de complètement nouveau aura un impact direct sur le chiffre d'affaires ou les résultats, et alors ils construisent ce workflow. Cela nécessite d'être un expert du "Mom's test" (lisez le livre), de comprendre que les clients ne se soucient pas de votre fonctionnalité mais de la façon dont ils peuvent mieux faire des affaires, de comprendre ce dont votre produit est capable et de livrer à un rythme rapide afin de pouvoir itérer avec le client sur le workflow en direct.
Voici donc la définition que j'afficherais au mur. Le déploiement sur site, c'est se tenir dans la distance entre ce que vous avez livré et ce dont le client avait besoin, combler cette distance de vos propres mains, dans leur monde, d'une manière qui apprend à votre produit à la combler seul la prochaine fois.
C'est dans la seconde moitié de cette phrase que presque tout le monde échoue.
Pourquoi c'est soudainement partout
Pendant soixante-dix ans, les logiciels aidaient les gens à faire le travail. Maintenant, ils commencent à faire le travail. Cela inverse une hypothèse cachée. Un outil peut se permettre d'être adopté lentement. Un travailleur, non. Le moment où vous vendez des résultats au lieu de licences, quelqu'un doit faire en sorte que le résultat se réalise à l'intérieur d'une entreprise qui ne se comporte pas du tout comme votre environnement de démo.
Les modèles ont cessé d'être la contrainte quelque part au cours des deux dernières années. Le déploiement est devenu la contrainte. L'étude la plus citée sur les pilotes d'IA en entreprise a révélé qu'environ dix-neuf sur vingt ne produisaient aucun impact mesurable sur le P&L, et l'autopsie n'est presque jamais la qualité du modèle. C'est un logiciel qui n'a jamais appris le workflow. Le processus documenté comporte quatre étapes. Le vrai en a neuf, et les cinq manquantes vivent dans la mémoire d'une femme, dans un tracker personnel qu'elle a construit il y a des années, et dans une faveur qu'elle échange avec une autre femme dans un autre bâtiment. Dans les industries plus anciennes, le travail passe par des systèmes installés avant la naissance de vos ingénieurs, maintenus ensemble par des fax et des appels téléphoniques. Rien de tout cela n'a d'API. Dans les champs pétrolifères, quelqu'un colle son oreille contre l'appareil de forage pour évaluer si le son indique quelque chose d'inquiétant. Sur le navire qui transfère des calmars de l'Inde aux États-Unis, avec une escale à Londres, les taux et les prix sont décidés en fonction de l'intuition, de données météorologiques limitées et de ce qui semble visuellement être la qualité du stock. La connaissance tribale est la couche porteuse de chaque entreprise, et personne n'a jamais livré un SDK pour cela. Le cimetière des plateformes industrielles de la dernière décennie a enseigné cette leçon avec des milliards de dollars. Les transformations ne meurent pas dans l'architecture. Elles meurent à l'adoption.
L'argent l'a remarqué. Microsoft a engagé deux milliards et demi de dollars et six mille personnes pour intégrer des experts chez les clients. AWS a mis un milliard derrière la même idée quelques semaines plus tôt. OpenAI et Anthropic ont chacun créé des sociétés de déploiement dédiées avec certains des plus grands investisseurs mondiaux derrière elles. Vous pouvez appeler cela une mode. Un capital à cette échelle est rarement un costume. Les laboratoires ont évalué leurs propres pipelines et ont découvert que l'acheteur n'avait jamais manqué d'intelligence. L'acheteur manquait de mains. L'échec réside dans le dernier kilomètre, et le dernier kilomètre est l'endroit où le fossé se creuse. Il a fallu 10 ans de travail acharné sur les LLM pour arriver là où nous sommes. Il pourrait en falloir beaucoup plus si nous voulions que ces modèles aient une compréhension du workflow et du cadre de décision humain.
Pourquoi avez-vous besoin d'un commercial dans cette équipe
L'ingénieur existe parce que l'écart est comblé avec du code, sur l'infrastructure du client, face aux cas limites du client, généralement en quelques jours. Ce que les utilisateurs décrivent le matin devrait fonctionner devant eux en quelques jours, pas en trimestres. Cette vitesse est la façon dont la confiance se construit avec des personnes qui ont regardé des programmes de transformation de trois ans produire une bibliothèque de slides.
Le commercial existe parce que les problèmes les plus difficiles du déploiement ne sont pas techniques, et prétendre le contraire est la façon dont les équipes techniques échouent. Quelqu'un doit découvrir ce qu'est réellement le travail avant que quiconque ne l'automatise. Quelqu'un doit décider lesquelles des vingt escalades comptent, quel workflow est le véritable goulot d'étranglement, le silence de quel dirigeant tuera l'adoption, et quel résultat justifierait l'ensemble de l'engagement. Quelqu'un doit être bon pour lire quand un client hésite et quand il dit des choses juste pour être poli. Quelqu'un doit gérer l'interface la plus délicate de l'IA d'entreprise, celle entre ce que votre produit fait aujourd'hui et ce que vous avez vendu comme inévitable dans six mois. Je considère le stratège de déploiement comme le "futures desk" de l'entreprise. Ils vendent ce que le produit deviendra, à un prix que la relation peut supporter, et ils s'assurent que la position ne fait jamais défaut. Les deals à enjeux élevés se gagnent sur ce desk, et se perdent sans lui.
Les modes d'échec vous disent quel rôle vous manquez. Les deals qui stagnent parce que le produit ne fonctionnera pas dans l'univers du client ou les scénarios où le produit ne supporte que les workflows qui existent à l'intérieur du produit signifient qu'il vous manque l'ingénieur. Les ingénieurs qui livrent des fonctionnalités demandées et sont occupés mais dont les revenus n'augmentent pas autant, ou les scénarios où le FDE a fait plus de 100 appels mais où les revenus contractés sont encore d'un ordre de grandeur supérieurs aux revenus réalisés, ou les silos de workflows personnalisés qui n'améliorent pas le système signifient qu'il vous manque le stratège.
Dans les meilleures équipes, les deux rôles se confondent, et cette confusion est le but. L'ingénieur développe l'instinct commercial, le stratège apprend à lire un schéma, et ce que vous obtenez est la chose la plus proche d'un fondateur qu'une entreprise puisse embaucher. Le déploiement sur site est ce que chaque fondateur fait pendant des années avant que l'organigramme ne le cache, assis dans le désordre des clients, fermant le travail avec ce qui est à portée de main, laissant ce qu'ils apprennent redessiner le produit. Le rôle est une semaine de fondateur sur la table de capitalisation de quelqu'un d'autre. C'est aussi pourquoi ces équipes produisent des fondateurs à un taux qui embarrasse les grandes technologies. Si vous dirigez un pod FDE, vous devriez vous préparer avec une succession planifiée dès le premier jour, car il y a de fortes chances que les fondateurs qui construiront une décennie plus tard aient tous été des FDE dans leur vie antérieure, qui se déroule aujourd'hui.
Comment savoir si vous en avez vraiment un
Vous ne pouvez pas juger une équipe de déploiement sur site à partir d'un instantané, car un jour donné, une grande équipe et une fausse se ressemblent : des gens intelligents qui prennent l'avion pour aller chez les clients et livrent des exploits. Cinq vérifications le révèlent.
#1 Effort par client. Une équipe qui a servi cinq clients l'année dernière et en sert cinq cette année ne cumule rien. Une équipe qui en sert maintenant quinze alimente un produit qui absorbe ce que le terrain apprend. Avec chaque client, en interne, votre équipe devrait développer un expert métier.
#2 La nouveauté du travail. Si le quatrième déploiement répète le troisième, personne n'est propriétaire du pipeline du terrain vers la plateforme. Quelqu'un doit être payé pour traquer la répétition entre les comptes, car la répétition est la roadmap qui s'écrit d'elle-même.
#3 La forme du deuxième déploiement dans un segment. Si le client dix vous coûte ce que le client un vous a coûté, vous ne passez pas à l'échelle d'un produit. Vous franchisez un projet.
#4 La ligne hiérarchique. À l'intérieur du produit ou de l'ingénierie, la boucle peut se fermer. À l'intérieur d'un silo de vente ou de services, l'apprentissage part dans des rapports de voyage que personne ne lit, et l'équipe devient silencieusement de la marge.
#5 Le propre tableau de bord du client. L'activité est du théâtre. Les chiffres d'utilisation peuvent être spectaculaires alors que rien ne s'améliore en aval. La seule mesure qui survit au contact avec un CFO est une évaluation que le client a aidé à rédiger, notant le travail par rapport à ses résultats sur ses données, construite à la semaine 1 et suivie ouvertement. Gardez un test humain à côté. Quand quelque chose casse dans leur entreprise qui n'a rien à voir avec votre produit, êtes-vous le premier appel ? Chaque tableau de bord jamais construit est une tentative d'approximer cet appel téléphonique.
Et surveillez le pattern sombre, car il est partout en ce moment. Dans certaines entreprises, l'équipe de déploiement sur site n'est pas un moteur d'apprentissage mais un cache-misère. Le produit ne fonctionne pas tout à fait, donc un humain est posté à chaque écart. Parce que les humains sont héroïques, les écarts n'atteignent jamais la roadmap. Parce que les écarts n'atteignent jamais la roadmap, le produit ne s'améliore jamais, et les humains ne peuvent jamais partir. Le produit ne ressent aucune pression parce que le terrain continue d'absorber. Le terrain n'écrit rien parce qu'il est trop occupé à sauver des comptes. Les factures continuent d'arriver parce que le client est, en fait, servi. La machine est en équilibre, et l'équilibre est le problème. Les entreprises vivent à l'intérieur pendant des années, augmentant les effectifs de terrain exactement aussi vite que les clients et appelant cela du déploiement sur site. Ce n'en est pas. C'est l'absence d'un produit, facturée mensuellement. C'est aussi pourquoi tant de personnes talentueuses dans ces postes ont l'impression d'échouer. Elles ont été embauchées pour cumuler et dotées en personnel pour cacher.
À quoi cela ressemble à chaque étape
Premier stade, ne l'embauchez pas. Soyez-le. Les fondateurs sont l'équipe déployée sur le terrain, et la pire chose que vous puissiez faire avec votre compréhension limitée est d'en déléguer l'acquisition. Faites vous-mêmes les déplacements de deux jours. Asseyez-vous avec le répartiteur. Quand vous embauchez enfin, embauchez des personnes qui vous rendent plus rapide pour finaliser le travail, jamais des personnes qui se mettent entre vous et le client.
Le stade de croissance est celui où le déploiement sur le terrain est mal compris, car vu de l'extérieur, cela ressemble à un ralentissement. Votre conseil d'administration voit des ingénieurs passer des semaines dans un seul compte pendant que les concurrents annoncent des fonctionnalités chaque semaine. La comptabilité aggrave les choses. Le déploiement est classé dans le coût des revenus alors que le travail se comporte comme de la R&D, donc plus vous apprenez, plus vous avez l'air mauvais. Tenez les deux vérités sans mentir dans un sens ou dans l'autre. Dans le grand livre, c'est un coût. En stratégie, c'est de la recherche. La solution n'est pas une histoire, ce sont des garde-fous qui obligent la recherche à payer. Limitez chaque engagement dans le temps. Liez chacun à un seul résultat commercial nommé. Récoltez trimestriellement, c'est-à-dire que chaque trimestre, quelque chose que le terrain a construit à la main devient quelque chose que la plateforme fait seule. « Nous le produitiserons plus tard » est la phrase qui tue les entreprises à ce stade, car « plus tard » n'a pas de propriétaire.
À grande échelle, la question change de forme. Vous avez des centaines de clients qui paient des millions, et vous employez déjà des consultants en solutions, des équipes de mise en œuvre, des services gérés, des responsables de comptes, des équipes de réussite client. Les dirigeants à ce stade ne savent vraiment pas où placer une équipe déployée sur le terrain, elle est donc ajoutée comme un quatrième niveau de support et meurt sous le volume de tickets. La réponse est que chaque fonction existante exécute un playbook, et l'équipe déployée sur le terrain n'existe que là où il n'y a pas de playbook. Les dix comptes les plus ambitieux. La nouvelle verticale. Le flux de travail que toute l'industrie dit impossible à automatiser mais que vous sentez que vous seul pouvez automatiser. Elle relève du produit, elle a pour mission de rendre son propre travail inutile, et elle transmet chaque schéma résolu aux équipes qui exécutent les playbooks, c'est ainsi que les playbooks restent vivants. La version d'Uber est instructive. Ils ont associé leurs ingénieurs les plus compétents en IA à des experts métier de la finance, du juridique et du support, ont donné deux semaines à chaque binôme, et ont exigé de construire aux côtés de la personne qui possède le flux de travail plutôt que de lui présenter. Deux jours d'observation, un jour pour choisir la cible, en ligne au dixième jour. Seize pods ont réorganisé seize fonctions en deux mois, et un rapport qui prenait deux jours prend maintenant dix minutes. L'unité d'automatisation n'a jamais été la tâche. C'est le flux de travail, et les flux de travail ne se révèlent qu'aux personnes qui sont à l'intérieur.
Le même métier porte des habits différents dans chaque secteur
Dans la défense et le gouvernement, la présence est le produit. Habilitations, réseaux déconnectés, salles que votre ordinateur portable ne peut pas quitter. Dans la santé, le travail est l'archéologie du workflow. Le véritable processus traverse des systèmes d'enregistrement vieux de vingt ans, avec des télécopieurs et des arborescences téléphoniques qui portent encore les exceptions, chaque établissement exécutant sa propre variante non écrite. Une équipe qui suppose un standard quelconque perd un an. Dans les services financiers, le client achète du jugement sous conformité, le livrable est souvent une évaluation qu'un régulateur pourrait lire, et l'anxiété la plus profonde n'est pas la fuite de données mais la fuite de jugement, les schémas de décision de leurs meilleurs employés qui entrent dans le modèle d'un autre. Dans la fabrication et la logistique, la vérité vit sur le terrain et les contraintes sont physiques, c'est pourquoi la découverte ne peut pas se faire par vidéo et les systèmes d'enregistrement sont archaïques, visiblement complexes et souvent déconnectés du cloud. Dans les entreprises grand public, la boucle tourne en jours plutôt qu'en trimestres, et la compétence rare est le goût, savoir à quoi ressemble la marque et quand une machine doit arrêter de parler. Et le territoire le plus récent est votre propre entreprise. Les mêmes pods, déployés dans vos propres fonctions finance, juridique et support, car l'écart entre ce que l'IA peut faire et ce que votre organisation fait réellement est le même écart, à un bâtiment d'écart.
Le terrain dicte les tactiques, et les tactiques sont négociables mais la séquence ne l'est pas. Asseyez-vous avec le travail, finalisez le travail, nourrissez le produit.
Qui est vraiment bon dans ce domaine
L'inventeur, Palantir, continue de faire fonctionner la version la plus profonde, et le détail que tout le monde oublie est que le modèle est né avant le produit. Au début, il n'y avait rien à configurer, seulement un pari que si vous restiez assez longtemps à l'intérieur d'institutions brisées, les produits se révéleraient. Ils se sont révélés, et aujourd'hui la même entreprise réalise des engagements plus courts et plus standardisés, car une fois que le produit existe, la capitalisation est la religion.
La nouvelle génération est plus facile à lire dans les entreprises d'agents de service client. Sierra gère sa fonction terrain comme des ingénieurs d'agents, et la boucle est délibérée. Résolvez-le pour un client, diffusez ce qui a fonctionné au sein de l'entreprise, puis faites passer les gagnants dans la plateforme pour que chaque client en hérite. Lorsque leurs ingénieurs ont appris, au cours de dizaines de déploiements, exactement quand un agent doit arrêter de réessayer et passer le client à une personne, ce jugement est devenu un composant réutilisable. Puis ils ont construit Ghostwriter, un agent qui fait la construction, alimenté par des transcriptions d'appels, des SOP et des photos de tableaux blancs, fonctionnant sur une plateforme qu'ils ont réarchitecturée pour qu'un agent puisse l'utiliser directement. Parier sur Sierra, c'est en grande partie parier que ses équipes déployées continueront de découvrir des workflows que personne d'autre n'a vus. Decagon a emprunté la voie des systèmes, a audité ses déploiements pour trouver les travaux qui n'avaient aucune raison d'être sur mesure, a réduit de quatre-vingts pour cent l'ingénierie personnalisée derrière chaque agent, puis a dit tout haut ce que tout le monde pensait tout bas, à savoir que la livraison, et non le produit, devenait le fossé défensif. Ramp recrute massivement son équipe terrain parmi d'anciens fondateurs, les oriente vers l'ensemble du cycle de vie client, du premier appel au support de longue traîne, et inculque une habitude avant tout : remettre en question l'exigence avant de la construire, car la demande formulée est généralement le symptôme, pas la maladie.
Une fois que vous connaissez la forme, vous la voyez dans chaque verticale sérieuse. Harvey intègre d'anciens avocats en exercice dans des cabinets d'avocats, preuve que la personne déployée n'a pas besoin d'être un ingénieur du tout, seulement d'être responsable. Dans la finance, Rogo recrute près de la moitié de l'entreprise avec d'anciens banquiers déployés dans les institutions d'où ils viennent, tandis que Hebbia envoie des ingénieurs pour construire le dernier kilomètre au sein des plus grands gestionnaires d'actifs du monde. Abridge met en place des pods de déploiement avec des systèmes hospitaliers, car amener un scribe IA à douze mille cliniciens n'est pas une installation, c'est une campagne. HappyRobot s'intègre avec des courtiers en fret, Gecko Robotics place des constructeurs sur des navires de la marine, Applied Intuition est présente chez la plupart des grands constructeurs automobiles mondiaux, et Cursor (SpaceX) dirige une équipe déployée sur le terrain qui connecte l'outil que vos ingénieurs aiment déjà aux banques et aux télécoms.
Des formes différentes, une seule physique. Le terrain alimente l'usine, ou ce n'est pas du déploiement sur le terrain.
L'argument le plus fort contre, car il en mérite un
Il y a un argument selon lequel toute cette profession est une excuse. On vous a vendu une cuisine qui cuisine toute seule, et elle est arrivée avec un chef qui vit maintenant dans votre maison, sur votre masse salariale, avec la marge du fournisseur, sans date de départ. Le pitch vous oblige à croire deux choses à la fois : que la machine est assez brillante pour remplacer votre cuisine et assez impuissante pour avoir besoin d'un gardien résident. Si le produit a besoin d'un humain résident, le produit n'est pas fini.
Prenez cela au sérieux, car pour de nombreux fournisseurs, c'est tout simplement vrai. Le test qui sépare les espèces est le même que cet article ne cesse de répéter. Si l'humain dans l'écart est permanent, la critique gagne et vous louez un correctif. Si l'humain dans l'écart est en capitalisation, finalisant le travail d'une manière qui supprime le besoin de lui-même, la critique meurt au deuxième déploiement. Ce qu'elle omet, c'est que la plupart du travail n'a jamais été de la finition de produit. C'est de l'acquisition de contexte. Les cinq étapes non documentées, l'intuition non dite du répartiteur, la faveur échangée entre bâtiments. Aucun produit fini ne sera jamais livré avec cela, car ils sont différents dans chaque entreprise. Quelqu'un doit aller les chercher. La seule question qui compte est de savoir si ce qu'ils rapportent se transforme en un actif ou s'évapore en factures.
Où cela mène
Quatre changements sont déjà en cours.
Le contexte devient l'actif. Ce qu'une équipe déployée construit vraiment chez chaque client, c'est un modèle de fonctionnement de cette entreprise. L'ontologie, le jumeau, la carte de qui décide quoi et pourquoi. Les investisseurs ont commencé à l'appeler le cerveau de l'entreprise, et le nom colle car chaque entreprise va en avoir besoin. Une plus grande partie de cela que les gens ne le pensent peut être amorcée avant que quiconque ne monte dans un avion, car les clients fuient constamment leur propre vérité, dans les tickets de support, les transcriptions d'appels, les e-mails, les fils d'escalade. Commencez là. Mais la couche la plus profonde, la connaissance que les gens ne peuvent pas verbaliser, nécessite encore une présence et des miroirs, des outils qui permettent aux initiés d'auditer leur propre intuition jusqu'à ce qu'elle devienne logique. Quiconque détient cette carte détient le compte, ce qui soulève la question que chaque PDG va poser à chaque fournisseur d'IA. Je loue l'intelligence, mais qui possède l'apprentissage ? Si un modèle partagé absorbe le jugement de crédit de chaque prêteur sur un marché, le souscripteur le plus avisé du pool forme ses concurrents et paie pour le privilège. Il y a un test que tout directeur financier peut faire. Changez de fournisseur de modèle demain, sur le papier, et vérifiez si tout ce que vous avez appris au système sort avec lui. Attendez-vous à ce que les contrats, les équipes et finalement les entreprises se réorganisent autour d'une seule ligne. Louez l'intelligence, possédez l'apprentissage.
Les agents rejoignent l'équipe. L'agent déployé sur le terrain existe déjà sous des formes précoces. Des agents d'intégration qui compriment un après-midi de travail d'intégration en quelques minutes. Des agents de déploiement qui lisent leurs propres transcriptions pendant la nuit et proposent des améliorations à leurs propres compétences. Regardez ce que cela fait au rôle humain. Chaque intervention manuelle cesse d'être le travail et devient un signal d'entraînement, et le travail de l'équipe s'inverse, passant de la réalisation de déploiements à la gestion de l'usine qui effectue les déploiements. La modélisation des effectifs comme les managers modélisent les personnes. La rédaction d'évaluations comme les managers rédigent des bilans. L'inversion plus profonde concerne qui est l'utilisateur. Les produits sont reconstruits pour que les agents puissent les utiliser directement, et la première question de découverte chez un client change silencieusement de « de quoi votre équipe a-t-elle besoin » à « de quoi votre agent a-t-il besoin ». Le même retournement frappe le côté revenus, où une personne avec une flotte d'agents gère désormais le pipeline qu'un étage de personnes gérait auparavant, et le logiciel post-vente se rebaptise d'outils en services propriétaires de résultats, la rétention en tant que service aujourd'hui, l'expansion en tant que service demain. Et quand les agents de vos clients commencent à négocier avec vos agents, les humains restants des deux côtés de la table feront les deux choses que les boucles ne peuvent pas fermer seules : décider ce qui vaut la peine d'être voulu et certifier que cela s'est réellement produit.
Le plancher s'effondre. Les déploiements qui coûtaient cinq millions de dollars d'ingénierie d'élite il y a quelques années coûtent maintenant quelques centaines de milliers et un généraliste avisé avec de bons agents, et le prix continue de baisser. Le déploiement sur le terrain cesse d'être un luxe du Fortune 500 et devient la façon dont les logiciels de milieu de marché sont vendus. La contrainte cesse d'être l'offre d'ingénierie et devient l'offre de jugement.
Le titre se dissout. Chaque ingénieur dans une entreprise sérieuse devient en partie déployé sur le terrain. Les ingénieurs backend participent aux appels clients. Les ingénieurs produit livrent à partir de transcriptions d'appels. Bientôt, le pourcentage de temps passé face au client sera la seule différence entre un FDE et un ingénieur logiciel, et les titres cesseront de faire semblant. Ce qui comporte un avertissement que personne n'imprime dans les offres d'emploi. Ce travail transforme les bâtisseurs en diplomates, et de nombreux ingénieurs brillants ont choisi de construire précisément parce que les salles pleines d'inconnus les épuisent. Respectez l'introverti en ne le déployant pas, et respectez le rôle en ne l'utilisant jamais comme un endroit où garer les ingénieurs qui étaient médiocres en ingénierie. C'est le contraire. C'est là que vous envoyez les personnes à qui vous confieriez la création de quelque chose.
Le plus vieux métier de l'entreprise
Enlevez la terminologie et le déploiement sur le terrain est la posture originale du fondateur, maintenue en vie au sein d'une entreprise qui a grandi assez pour l'oublier. Asseyez-vous là où est le travail. Finalisez le travail. Laissez ce que vous avez appris changer ce que vous construisez. Chaque entreprise durable a fait cela avant d'avoir un nom pour cela. La plupart des entreprises arrêtent de le faire le jour où elles peuvent se le permettre.
Donc la vraie question n'a jamais été de savoir s'il fallait embaucher des ingénieurs déployés sur le terrain. C'est de savoir si vous êtes prêt à diriger une entreprise où les personnes les plus proches de la réalité ont un réel pouvoir, où l'effort est jugé par sa pente, et où rien de ce qui est appris sur le terrain n'est autorisé à y mourir. Construisez cela, et le titre s'occupe de lui-même.
Quelle est la dernière pièce de travail que votre équipe a finalisée si complètement que le client a cessé d'y penser ? Quand est-ce qu'un client a renouvelé pour la dernière fois non pas parce qu'il a tiré de la valeur de votre suite de produits, mais parce qu'il sait que vous allez construire des choses dont il ne savait même pas qu'il avait besoin pour développer son entreprise ? Commencez à compter à partir de là.
