Jamais ceux qui vendent une technologie n'ont autant crié qu'elle était dangereuse. Et jamais leurs clients n'ont autant payé pour les laisser entrer chez eux. Ce qui ressemble à un paradoxe est en réalité un business model : la peur comme passe-partout, la dépendance comme abonnement.
Pourquoi vendre un produit en criant qu'il est dangereux ?
Dans toute l'histoire de la tech, le marketing a toujours eu le même réflexe : rassurer. L'avion est sûr, le cloud est sécurisé, le paiement est chiffré. Celui qui vend du progrès vend de l'absence de risque.
Avec l'IA générative, le scénario s'est inversé. Les mêmes voix qui vendent la technologie égrènent en boucle la liste de ses dangers : hallucinations, fuites de données, non-conformité réglementaire, biais, shadow AI, et même, certains jours, risque existentiel. Ouvrez les livres blancs, écoutez les keynotes : moitié argumentaire commercial, moitié notice d'avertissement.
Un paradoxe ? Non. Une stratégie. Car la peur est la seule émotion qui produise simultanément trois effets commerciaux : elle suspend l'esprit critique, elle débloque des budgets qui ne passeraient jamais en climat calme, et elle justifie l'impensable — confier les clés de son propre système d'information.
Déroulons la mécanique, elle est implacable :
- On installe la peur : « L'IA est instable, dangereuse, elle hallucine, elle peut ruiner votre entreprise si elle est mal utilisée. »
- On crée le besoin : les grands comptes paniquent. Ils ne peuvent pas se permettre de se planter.
- On propose la solution « sécurisée » : « Confiez-nous votre infrastructure, on installe, on paramètre, on supervise tout. »
- On s'incruste : les équipes du vendeur deviennent des acteurs internes qui voient tout, comprennent tout, et finissent par contrôler votre compréhension de l'IA dans votre propre maison.
Le reste de cet article tient en deux mots : dépendance et incrustation. Et pour ceux qui y verront de la paranoïa, bonne nouvelle : rien de tout cela n'est caché. C'est public, annoncé, célébré — sur les blogs officiels des vendeurs, avec les montants en dollars.
Partie 1 — L'évangile de la peur
Soyons honnêtes deux secondes : la prudence existe bel et bien. Les hallucinations sont réelles, les fuites de données sensibles dans des chats publics aussi, les biais également. C'est précisément ce qui rend le mécanisme imparable : il s'appuie sur du vrai. Personne ne peut dire « cette peur est fausse ». Non — la peur est réelle. Ce qui est industriel, c'est son exploitation commerciale.
Observez le vocabulaire. « IA responsable », « gouvernance », « compliance », « enterprise-grade », « trust & safety » : ce ne sont plus des contraintes que le fournisseur assume, ce sont des tranches de pricing facturées au client. La sécurité est devenue le meilleur argument de marge de l'histoire du logiciel. On ne vous vend plus un modèle : on vous vend le droit de dormir tranquille, et le supplément « tranquillité d'esprit » n'est jamais en promotion.
Mieux encore : regardez qui réclame de la régulation. Les grands laboratoires eux-mêmes montent au créneau pour appeler à des règles strictes — geste citoyen en apparence, ticket d'entrée en réalité. Se conformer à un cadre réglementaire complexe coûte des millions ; seuls les géants peuvent se le payer. Chaque nouvelle contrainte élimine un petit acteur, un modèle open source, une alternative européenne, et consolide le marché au profit des incumbents. C'est le scénario de la banque post-2008 rejoué en accéléré : des règles censées dompter les géants ont fini par les protéger de la concurrence.
Sur le terrain, cela produit un climat anxiogène saturé. Une DSI bombardée d'articles alarmistes et de mises en demeure mentales finit par intérioriser une équation simple : construire en interne = prendre un risque ; acheter chez le plus gros = se couvrir. La peur ne protège plus l'entreprise. Elle protège les parts de marché du vendeur.
Partie 2 — La peur, sésame pour les directions générales
Les grands comptes ont de vraies raisons d'avoir peur : données régulées, audits, sanctions, image de marque. Une banque ne peut pas se permettre un chatbot qui invente des taux ; un énergéticien, une fuite de données sensibles ; un assureur, un biais documenté dans un verdict. La peur n'est pas absurde : elle est rationnelle. C'est pour ça qu'elle fonctionne.
Alors qu'achètent-ils, au juste ? Plus une performance : un transfert de risque. Une tranquillité d'esprit. Un alibi de direction générale : « nous avons pris le leader du marché, nous sommes couverts ». C'est le vieux théorème « personne ne s'est jamais fait virer pour avoir acheté IBM », mis à jour à l'ère des transformers. On n'achète plus un outil, on achète la version moderne de l'assurance-vie managériale.
À cette peur s'ajoute un second levier : la pénurie de compétences. « Vos équipes ne savent pas faire, les nôtres si. » L'entreprise, persuadée d'être en retard et maladroite, ouvre grand ses portes. Et ce qui entre par la porte n'est plus une clé de licence : ce sont des gens.
Le tableau de l'été 2026 est édifiant. OpenAI lance une « Deployment Company » et rachète la société Tomoro pour disposer d'ingénieurs « déployés à l'avant » (Forward Deployed Engineers) chez ses clients « dès le premier jour ». Fin juin 2026, AWS investit un milliard de dollars dans une organisation de Forward Deployed Engineering qui embarque des milliers d'experts directement chez les clients. Quelques jours plus tard, Microsoft dégaine Microsoft Frontier Company : 2,5 milliards de dollars et 6 000 ingénieurs intégrés chez les grands comptes pour « construire et faire tourner leurs systèmes d'IA ». Dès février, OpenAI signait des partenariats pluriannuels avec les géants du conseil — Accenture, BCG, Capgemini, McKinsey — pendant qu'Accenture équipait des dizaines de milliers de consultants de ChatGPT Enterprise.
Soyons clairs : ce n'est pas un complot secret, c'est un organigramme. Le métier de Palantir — pionnier du rôle d'ingénieur embarqué — est devenu le standard de l'industrie en dix-huit mois. Et le vocabulaire lui-même est un programme : forward deployed. Pas « support ». Pas « formation ». Deployed. Comme on déploie des troupes.
Partie 3 — L'incrustation silencieuse : du vendeur à l'observateur, de l'observateur au co-pilote
Voyons ce que « déployé » signifie, vu de l'intérieur. Pour « accompagner » une banque, il faut voir ses flux. Pour « paramétrer le modèle sur votre cas d'usage », il faut lire vos données. Pour « superviser », il faut des accès. Et les accès, une fois donnés, ne se reprennent presque jamais.
Ces équipes voient donc vos flux financiers, vos brevets, votre politique tarifaire, votre organisation RH, vos données clients, vos faiblesses internes. Elles cartographient votre métier mieux que certains de vos propres dirigeants. Elles ne sont plus des fournisseurs : elles sont des observateurs. Et un observateur qui sait tout, chez vous, n'est plus vraiment extérieur.
Pire : elles formatent votre culture. Elles rédigent vos cahiers des charges (avec leurs outils), forment vos équipes (à leurs produits), auditent vos usages (à l'aune de leurs standards), arbitrent vos choix (dans leur intérêt). Elles ne sont plus sous votre contrôle : elles contrôlent votre compréhension de l'IA à l'intérieur de vos propres murs. Le verrouillage n'est plus seulement technique, il est cognitif.
Le conflit d'intérêts, lui, est structurel — c'est même le cœur du modèle : celui qui a installé la peur est le seul à pouvoir la dissiper. L'incendiaire salarié de la caserne. Envie d'un second avis ? Le second avis est évalué par le premier. Envie de changer de modèle ? Vos « superviseurs » maison plient bagage, et la peur revient au galop, calibrée au millimètre. Comme ils ont créé la peur, ils sont les seuls à pouvoir la dissiper. Puissant, non ?
On a déjà vu ça : les intégrateurs SAP/Oracle, les cabinets qui rédigent les specs des appels d'offres qu'ils remportent. Mais trois choses ont changé. L'objet est opaque — on ne regarde pas dans le modèle. Il est vivant — mises à jour continues, le paramétrage d'hier n'est pas celui de demain. Il est central — des décisions assistées par l'IA partout dans la chaîne de valeur. Ce qui prenait dix ans avec un ERP en prend dix-huit avec l'« accompagnement ».
Partie 4 — Le coût caché : payer une fortune pour se faire coloniser
La facture a quatre lignes, et une seule est visible.
La ligne visible : licences premium, contrats « enterprise », audits, accompagnement, tickets d'entrée à plusieurs millions. L'entreprise paie une fortune — c'est la ligne que le CFO signe en croyant acheter de la sécurité.
Deuxième ligne, la souveraineté : vos cas d'usage affinent leur offre, vos données affinent leurs processus. Ce que vous croyez protéger alimente ce qui s'incruste.
Troisième ligne, la compétence interne : quand « les gens de l'IA » sont ceux du vendeur, les vôtres arrêtent d'apprendre. Le muscle s'atrophie. Dans trois ans, l'entreprise ne sait plus évaluer un modèle, rédiger un cahier des charges, négocier un contrat — puisque « eux » savent faire. On n'externalise pas une compétence, on l'ampute.
Quatrième ligne, la réversibilité : sortir coûte plus cher que rester. C'est la définition même du vendor lock-in, sauf que cette fois le verrou n'est pas dans la base de données : il est dans les têtes. Si demain l'entreprise veut changer de modèle, elle perd ses « superviseurs » maison, et la peur revient au galop.
Et le plus génial dans leur stratégie ? Le client finance lui-même l'opération. Il croit acheter de la sécurité, il achète une dépendance vitale. Il paie pour se faire coloniser, et il remercie dans le communiqué de presse. Le piège n'a même pas besoin de geôlier : l'otage se garde tout seul.
Innovation captive, décisions sous tutelle, compétence atrophiée : voici à quoi ressemble une entreprise qui a externalisé sa propre maturité numérique.
Conclusion : n'invitez pas le loup à compter les moutons
Disons-le pour éviter tout contresens : rien de tout ceci n'est un prétexte pour rejeter l'IA. La technologie est extraordinaire, et ceux qui ne feront rien par peur seront effectivement les perdants. Mais entre « faire » et « confier les clés », il y a un monde : le vôtre.
La vraie sécurité ne s'achète pas chez celui qui vous vend la peur. Elle se construit : maîtrise de son infrastructure, maîtrise de sa data, maîtrise de ses compétences. C'est le seul triptyque qui fait de vous un négociateur plutôt qu'un otage.
Quelques réflexes pour reprendre la main :
- Commencez petit, en interne, sur des cas d'usage non critiques — et apprenez avant d'acheter.
- Formez vos propres équipes avant de signer du « clé en main » : une compétence interne est le seul actif qui ne périme pas.
- Préférez l'ouvert et l'interopérable : modèles ouverts, standards, contrats réversibles. Rédigez la clause de sortie avant la clause d'entrée.
- Bornez contractuellement ce que les équipes embarquées peuvent voir, emporter et conserver.
- Traitez tout argumentaire de vente qui commence par la peur comme un signal faible : si le pitch débute par l'effroi, le produit vendu est la dépendance.
Ouvrir son système d'information à ceux qui ont organisé la peur pour qu'ils viennent vous « sécuriser », c'est exactement ce que le proverbe a toujours déconseillé : inviter le loup dans la bergerie pour compter les moutons. Sauf qu'aujourd'hui, les moutons paient eux-mêmes la facture du loup — et ils appellent ça « transformation numérique ».
Sources
- OpenAI — lancement de l'OpenAI Deployment Company et acquisition de Tomoro (ingénieurs Forward Deployed « dès le premier jour ») — openai.com
- IIT — le rôle de Forward Deployed Engineer, pionnier chez Palantir — iit.edu
- OpenAI for Business — partenariat Accenture, dizaines de milliers de consultants équipés de ChatGPT Enterprise
- CNBC (fév. 2026) — partenariats pluriannuels OpenAI × Accenture, BCG, Capgemini, McKinsey — cnbc.com
- IONOS — définition du vendor lock-in — ionos.fr
- GeekWire / CNBC (juil. 2026) — Microsoft Frontier Company, 2,5 Md$ et 6 000 ingénieurs embarqués chez les clients — geekwire.com
- About Amazon (juin 2026) — AWS investit 1 Md$ dans une organisation de Forward Deployed AI Engineers — aboutamazon.com
Article publié le 6 août 2026 — ExploDev.