Stratégie AI · 23 mai 2026 · 24 min. de lecture · Mohsen Ghulami, GTM Engineer, Amplifa

Stratégie AI : Build vs. Buy dans les PME industrielles

Stratégie AI dans les PME : décidez entre Build vs. Buy avec des chiffres, des cas concrets et des critères clairs avant que votre PoC ne dévore votre budget.

Il y a trois semaines, je me trouvais à Gütersloh dans une salle de réunion qui sentait le café filtre et le plastique chaud. Thomas, CTO d'un constructeur de machines de 280 personnes, me tend son iPad et me dit : « Nous construisons maintenant notre propre plateforme AI. » Dans la cour, un chariot élévateur recule en bipant ; à l'intérieur, une diapositive PowerPoint scintille avec le logo Azure, le serpent Python et un bloc budgétaire de 1,2 million d'euros. Ma première question n'était pas technique, mais brutalement simple : est-ce vraiment une stratégie AI — ou juste un détour coûteux vers le prochain logiciel standard ?

J'écris sur l'industrie depuis 1998. J'ai vu chez Trumpf à Ditzingen comment les données des machines de découpe laser deviennent une activité de service. J'ai vu chez de petits sous-traitants du Jura souabe comment l'absence d'un seul export MES arrête tout un projet AI. Et j'ai vu assez de CFO serrer les lèvres au mot « développement interne » comme s'ils avaient mordu dans un citron.

Le dilemme Build vs. Buy en matière d'AI n'est donc pas une question de foi. C'est une question d'allocation de capital. La PME de 50 à 500 employés qui veut construire elle-même chaque modèle de forecasting brûle son temps, ses salaires et ses nerfs. Mais celle qui achète chaque fonction AI, alors qu'elle fait la différence dans son propre produit, cède sa marge à des fournisseurs qui ne comprennent pas son métier. J'ai vu les deux. Les deux font mal.

Pourquoi la stratégie AI devient une priorité pour la direction

En mars 2025, j'étais chez un fournisseur près de Heilbronn, 410 employés, beaucoup d'usinage, peu de patience. Andrea, Head of Operations, m'a montré une ligne de six centres d'usinage DMG Mori. Le bruit était ce chant métallique dur que l'on connaît dans les halls où personne ne parle d'avenir parce que la commande doit sortir d'ici vendredi. « Nous avons quatre PoC AI », a dit Andrea. « Aucun n'est en production. »

C'est exactement là que se trouvent les PME. Non pas au début du débat sur l'AI, mais après les premières désillusions. ChatGPT a ouvert la porte en 2023, Microsoft Copilot est arrivé dans de nombreuses entreprises, SAP intègre des fonctions AI dans sa suite, et un fournisseur de logiciels sur deux colle désormais une étiquette AI sur sa roadmap. Seulement voilà : dans l'atelier, aux ventes, au service, il se passe moins de choses que ce que prétendent les scènes de conférence.

Les chiffres confirment cette observation. Selon l'étude BITKOM 2024, environ 15 à 20 % des entreprises en Deutschland utilisent l'AI de manière productive ; pour les entreprises de 100 à 499 employés, le taux se situe plutôt dans la fourchette basse, environ 10 à 15 %. Le BCG et la VDMA sont parvenus en 2023, dans le secteur de la construction mécanique, à un schéma que j'entends constamment en entretien : plus de 60 % expérimentent des PoC AI, mais moins de 15 % ont des applications à l'échelle dans l'entreprise. En résumé : beaucoup de pilotes, peu d'exploitation.

Ce n'est pas une fatalité en Germany. C'est souvent une mauvaise prise de décision. Les PME traitent trop souvent l'AI comme une acquisition technologique et trop rarement comme une question de création de valeur. Dans une entreprise de 180 employés à Augsbourg, Jens, directeur commercial, m'a dit en janvier 2025 : « Nous ne pouvons pas nous permettre d'erreur. » C'est vrai. Mais ne pas décider est aussi une erreur. Juste plus silencieuse.

Stratégie AI en PME : ce que Build vs. Buy signifie réellement

Build ne signifie pas que trois Data Scientists entraînent un Foundation Model à la cave. Enfin, presque jamais. Dans une PME, Build signifie généralement : propres pipelines de données, propres modèles ou du moins propre logique métier, propres processus MLOps, propre monitoring, propre responsabilité. Le fournisseur livre peut-être l'infrastructure Cloud, mais l'entreprise porte le risque produit et opérationnel.

Buy ne signifie pas que vous achetez un logiciel et que vous économisez 15 % de rebuts dès le lundi suivant. Quiconque croit cela n'a jamais vu d'interface entre un vieux ERP, un export Excel et une commande de machine. Buy signifie : acheter un logiciel standard, un SaaS ou des briques de plateforme, configurer, intégrer, former, mesurer. C'est du travail. Mais c'est un travail différent de la construction de modèles.

La frontière la plus nette ne passe pas entre Cloud et On-Prem. Elle passe entre Commodity et Différenciation. Forecasting, NLP standard, classification d'images, optimisation d'itinéraires, assistance aux offres, moteurs de recommandation simples — il existe des produits viables pour cela. L'AI au cœur du produit, comme des capteurs intelligents, la navigation autonome, le contrôle de processus propriétaire ou un algorithme de service qui apprend de 15 ans de données machines — là, le Build peut être judicieux. Peut. Pas doit.

PwC et Roland Berger décrivent depuis 2023 un schéma qui apparaît aussi dans mes échanges : les petites et moyennes PME optent majoritairement pour le Buy ou le Configure, les plus grandes PME choisissent plus souvent l'Hybride. L'entreprise de 300 personnes achète plutôt du Microsoft, SAP, Cognex, Celonis, o9, PTC ou un fournisseur spécialisé. Le fournisseur de 3 000 personnes construit peut-être un Analytics Competence Center et développe là où se trouve la valeur ajoutée. Cela semble banal. C'est pourtant ignoré en permanence.

Les chiffres bruts : coûts, délais, taux de réussite

Au cours des deux dernières années, à Munich, Stuttgart, Bielefeld et Linz, j'ai parlé avec des responsables du numérique qui gèrent leurs budgets AI non pas dans des communiqués de presse, mais dans Excel. Les fourchettes sont étonnamment stables. Un PoC Build en PME se situe généralement entre 100.000 € et 300.000 € pour trois à six mois. Pour qu'un MVP soit opérationnel, 300.000 € à 800.000 € sont réalistes, les coûts de personnel interne n'étant pas toujours calculés avec précision. Et c'est précisément là que commence l'auto-illusion.

Car le Data Scientist n'est pas gratuit simplement parce qu'il est déjà sur la liste de paie. L'ingénieur de production qui vérifie les labels huit heures par semaine non plus. L'architecte IT qui règle les autorisations de sécurité encore moins. Dans une usine près d'Ulm, ça sentait le lubrifiant réfrigérant en février 2025, tandis que Martin, responsable IT, me disait : « En externe, nous n'avons dépensé que 180.000 €. » Deux heures plus tard, il m'a montré l'estimation de l'effort interne. Avec les prestations propres, le projet s'élevait à 520.000 €.

Le Buy ou le Configure démarre plus bas. Licence pilote plus intégration : souvent 50.000 € à 250.000 €. Déploiement sur plusieurs usines ou départements : 150.000 € à 800.000 €. Les coûts de licence annuels pour de nombreux scénarios de PME se situent entre 50.000 € et 200.000 € par an, selon les utilisateurs, le volume de données et l'humeur du fournisseur. Oui, l'humeur du fournisseur. Quiconque a déjà négocié un renouvellement SaaS au cours de la troisième année de contrat sait de quoi je parle.

Les taux de réussite sont le véritable coup de massue. McKinsey a rapporté dans le State of AI 2023 que seulement 20 à 30 % environ des entreprises tirent des avantages financiers significatifs des projets AI. Dans la fabrication et les biens industriels, selon mon expérience et les benchmarks de consultants, 50 à 70 % des PoC meurent avant de voir une exploitation réelle. En Build, seuls 30 à 40 % franchissent souvent le pas de la production. En Buy ou Configure, plutôt 50 à 70 %. Non pas parce que les fournisseurs font de la magie. Mais parce qu'il y a moins de risque fondamental dans le modèle.

Le Build en vaut la peine — mais plus rarement que ne le prétendent les slides des fondateurs

J'aime le développement interne. Vraiment. Il y a ce moment où une équipe ne se contente pas d'entraîner un modèle, mais l'intègre dans un processus, où les utilisateurs le manipulent, où l'indicateur clé bouge et où le chef d'usine ne parle plus du « truc AI », mais de son nouvel outil. C'est puissant. Seulement, cela n'arrive pas parce que quelqu'un a installé PyTorch.

Trumpf est un bon exemple, mais aussi un avertissement. L'entreprise familiale de Ditzingen compte environ 16 500 employés, des données machines profondes, une propre histoire de plateforme avec AXOOM et un écosystème autour de TruConnect. Depuis environ 2017, Trumpf investit continuellement dans les services numériques, la Predictive Maintenance et les fonctions Smart Factory. Dans ses présentations publiques, Trumpf parle pour certaines installations d'une réduction allant jusqu'à 20 à 30 % des temps d'arrêt grâce à la maintenance préventive. Ce n'est pas un projet annexe de l'IT. C'est une activité de produit et de service.

Kärcher de Winnenden est tout aussi intéressant. Le KIRA B 50, un robot de nettoyage autonome, nécessite de la Computer Vision, de la navigation, de la fusion de capteurs et un logiciel robuste dans le produit physique. Un recommandeur standard du Cloud n'y aide guère. Kärcher a développé des compétences numériques depuis environ 2018, notamment au sein du Digital Hub, et combine son propre développement avec des briques Cloud. Ici, le Build n'est pas une question de prestige. L'AI est dans l'appareil, dans le prix, dans le contrat de service.

C'est là le point crucial : le Build est rentable quand l'AI modifie le bénéfice client ou reproduit un processus que les concurrents ne peuvent pas copier facilement. Un fabricant de machines-outils disposant de milliards de données de capteurs historiques a une base de départ différente de celle d'un grossiste de 220 personnes qui veut améliorer le cross-selling sur son webshop. Celui qui brouille ces différences met la charrue avant les bœufs.

Nous ne développons nous-mêmes que là où nous voyons un avantage concurrentiel clair et où notre connaissance des processus ou des produits est unique. Nous achetons l'Analytics standard et les modèles de langage.

— d'après les propos d'un CDO d'un constructeur de machines allemand, entretien Handelsblatt 2024

Nicole Büttner de Merantix Momentum a souligné quelque chose de similaire dans les formats EY sur « l'avenir de la Deutschland » : les PME ont un avantage avec leurs propres données, mais devraient souvent acheter des modèles et des plateformes tout en maîtrisant elles-mêmes la logique métier. Je souscris à cela. Les données seules ne sont pas encore un fossé défensif. Ce n'est que lorsque les données, la connaissance des processus et le canal de distribution se rejoignent que le Build devient intéressant.

Le Buy-first n'est pas une capitulation, mais une discipline

À Münster, j'ai rencontré en novembre 2024 un responsable logistique, Ralf, qui avait participé à des projets de prévision chez Fiege. Nous étions dans une cantine, ça sentait la sauce de rôti, et de l'entrepôt provenait ce roulement sourd de la technique de convoyage. « Nous aurions pu tout construire nous-mêmes », a-t-il dit. « Mais pour quoi faire ? » Fiege utilise dans différents domaines des services Cloud, des briques Azure et des solutions partenaires, par exemple pour les prévisions et l'optimisation. Les Use Cases publiés parlent d'une réduction des stocks de 2 à 5 % et d'une amélioration de la Forecast Accuracy de 3 à 8 %, selon le domaine.

C'est la réalité des PME, juste à une échelle supérieure. Un forecast est rarement unique. Une optimisation d'itinéraire non plus. Un contrôle qualité basé sur l'image avec une classe de défauts définie est techniquement exigeant, mais souvent pas une raison pour monter sa propre équipe Vision. Cognex, Landing AI, Microsoft Custom Vision, Siemens Industrial Edge, PTC ThingWorx ou des fournisseurs spécialisés ont leurs défauts. Bien sûr. Mais ils ne partent pas de zéro.

Un cas anonymisé du sud de la Deutschland montre bien la logique. Constructeur de machines, 800 employés, contrôle visuel manuel, manque de personnel, forte pression de retouche. L'entreprise a acheté un système Vision AI commercial au lieu de développer le sien. Investissement initial : environ 350.000 € pour le matériel, les licences, l'intégrateur et la formation. Quatre mois de PoC, trois mois de déploiement sur deux lignes. Après douze mois, le taux d'erreur était inférieur d'environ 30 %, amortissement en moins de 18 mois. Pas de prix de l'innovation. Mais de l'argent.

Je sais, le Buy semble trop petit pour certains CTO. On ne veut pas seulement « configurer ». On veut créer. C'est compréhensible. Seulement, le client ne paie pas pour la fierté du département IT. Il paie pour la capacité de livraison, la qualité, le service, la stabilité des prix. Si un logiciel standard apporte 80 % de l'utilité en un tiers du temps, alors le développement interne est souvent de la vanité avec une planification de sprint.

La seconde vérité : le Buy peut devenir coûteux, lent et dangereux

Maintenant, l'autocorrection. Buy-first ne signifie pas Vendor-first. J'ai vu des projets SaaS qui, après deux ans, ressemblaient à un appartement en location après dix sous-locataires : des adaptateurs partout, plus personne ne sait à qui appartient la clé. Un fournisseur de 260 personnes de Basse-Bavière a payé en 2024 des licences modérées pour trois outils proches de l'AI dans la vente, le service et la planification. Avec les interfaces, le conseil et les administrateurs internes, les coûts annuels ont soudainement atteint 310.000 €. L'utilité ? Difficilement mesurable. « Nous avons maintenant des tableaux de bord », a dit le chef des ventes. J'avais pitié de lui.

La plus grande erreur du Buy est la foi aveugle dans les fonctions. Une démo de logiciel montre toujours des données propres. Toujours. En exploitation réelle arrivent les doublons de fichiers clients, les hiérarchies d'articles manquantes, les modèles d'équipes divergents et un champ ERP nommé « Divers » qui contient depuis 2009 tout ce que personne ne voulait classer. SAP, Microsoft, Siemens ou PTC peuvent amortir beaucoup de choses. Mais ils ne réparent pas une organisation qui méprise ses données de base.

La deuxième erreur est le Lock-in sans contrepartie. Si un fournisseur contrôle l'ensemble de la gestion des données, la logique du modèle, l'interface utilisateur et l'intégration des processus, l'entreprise devient dépendante. Cela peut être acceptable si le Use Case est une Commodity et que le fournisseur livre de manière stable. Pour les processus critiques, il faut être plus prudent. Exportation des données, capacité d'audit, coûts lors de la mise à l'échelle, scénario de sortie — des sujets ennuyeux, oui. C'est précisément pour cela qu'ils sont lus trop tard.

Où meurent les projets Build dans les PME

Il y a une scène qui se répète. Salle de réunion, moquette grise, tableau blanc avec les restes d'un atelier, quelque part il est encore écrit « Priorisation des Use Cases ». Dans la salle se trouvent l'IT, le métier et un consultant externe. Après 14 mois de projet, quelqu'un demande : « Qui est au fait le Product Owner ? » Puis c'est le silence. J'ai vécu cela à Cologne, Nuremberg et Saint-Gall.

La première cause de décès s'appelle la qualité des données. Pas sexy, mais mortelle. Un équipementier automobile d'environ 3 000 employés a lancé sur trois ans plusieurs PoC de Predictive Maintenance, en collaboration avec un institut de recherche. Effort : plus d'un million d'euros, temps interne inclus. Tous les pilotes sont restés bloqués dans des installations isolées. L'OT et l'IT étaient séparés, il n'y avait pas de Lakehouse central, la maintenance a été impliquée tardivement, et l'historique des données ne correspondait pas à la logique des pannes. Après un changement de direction IT, le passage à une plateforme standard a été effectué. Neuf mois plus tard, les premiers Use Cases productifs tournaient ; après 18 mois, environ 15 % de pannes imprévues en moins étaient signalées sur des installations sélectionnées.

La deuxième cause de décès s'appelle la fausse fierté. Un distributeur B2B de la région DACH d'environ 1 200 employés a voulu construire son propre moteur de recommandation, aussi pour réduire sa dépendance aux plateformes Cloud américaines. Équipe de Data Science de cinq personnes, Python, Scikit-Learn, plus tard TensorFlow. Dix-huit mois de développement, environ 1 à 1,5 million d'euros. Au final, la performance selon les tests internes n'était que de 60 à 70 % de celle d'un recommandeur Cloud standard. Le projet a été arrêté, la solution SaaS est arrivée quand même. Juste plus tard et plus cher.

La troisième cause de décès est l'absence de pensée produit. L'AI est lancée comme un projet, pas exploitée comme un produit. Il y a un PoC, un rapport final, des applaudissements au comité de pilotage. Ensuite, le modèle dérive, personne ne mesure le taux d'utilisation, personne ne prévoit de réentraînement, personne ne se sent responsable des fausses alertes. Après six mois, le chef d'équipe dit : « Ce truc déconne. » Et voilà, l'acceptation a disparu.

Le MLOps n'est pas ici un buzzword, mais un travail de concierge pour les modèles. Monitoring, versionnage des données, processus de validation, rollback, responsabilités, piste d'audit. Ça a l'air sec. Ça l'est. Mais sans ces routines, l'AI devient un logiciel jetable. On construit, on montre, on oublie.

La matrice Build-vs.-Buy pour une stratégie AI robuste

J'aime utiliser une matrice 2×2 simple lors de mes échanges. Pas de magie. Sur l'axe X se trouve le potentiel de différenciation : cette fonction AI nous rend-elle plus difficiles à copier sur le marché ? Sur l'axe Y se trouve la standardisabilité : existe-t-il un logiciel mature qui couvre 70 à 80 % de la tâche ? Si les deux axes sont évalués honnêtement, de nombreux projets favoris passent à la trappe.

Quadrant un : fort potentiel de différenciation, faible standardisabilité. Ici, on peut sérieusement examiner le Build ou le Co-Build. Exemples : AI dans un appareil médical avec des capteurs spéciaux, fonctions autonomes dans une machine de nettoyage, contrôle de processus pour un procédé de production propre. Kärcher, Trumpf, Wittenstein ou Festo pensent dans ces catégories. Là, l'AI est proche du produit ou du secret de fabrication.

Quadrant deux : faible potentiel de différenciation, forte standardisabilité. Acheter. Point final. Forecasting standard, classification de texte au service client, chatbots simples, vérification des notes de frais, Lead Scoring, contrôle d'image avec des types de défauts connus. Celui qui prône le Build ici devrait mettre les coûts d'opportunité sur la table. Pas sous forme de slide. Sous forme de montant en euros.

Quadrant trois : fort potentiel de différenciation, forte standardisabilité. C'est la zone hybride passionnante. Un LLM peut générer des projets d'offres, mais la propre logique produit, les règles de remise, la capacité de livraison et les clauses de responsabilité doivent venir de l'entreprise. Microsoft Copilot ou SAP Joule peuvent fournir les interfaces, mais le cerveau métier réside dans son propre modèle de données. C'est précisément là que les PME devraient développer des compétences.

Quadrant quatre : faible potentiel de différenciation, faible standardisabilité. Généralement un signal d'alarme. Si quelque chose n'est ni stratégiquement important ni facile à acheter, pourquoi le faire ? Parce qu'un chef de département le veut ? Parce qu'un programme de subvention pointe le bout de son nez ? L'argent des subventions n'est pas un business case. Il n'y a pas à tortiller.

Calcul du ROI : pourquoi un démarrage moins cher peut finir par coûter cher

En juin 2025, un directeur de Ravensburg m'a appelé. 120 employés, construction de machines spéciales, bon EBIT, mais IT légère. Il a demandé : « Combien nous coûte une AI pour l'automatisation des offres ? » J'ai répondu par une question : « Combien coûte une offre aujourd'hui ? » Silence. Puis feuilletage. Puis le chiffre : environ 1.800 € d'effort interne pour des machines complexes, quand les ventes, la conception et les achats sont impliqués.

Ce n'est qu'avec de tels chiffres que le Build vs. Buy devient tangible. Si une entreprise rédige 900 offres complexes par an et qu'un système d'assistance AI réduit le temps de traitement de 25 %, nous ne parlons pas de gadget. Nous parlons de capacité, de réaction plus rapide, de moins d'erreurs dans les nomenclatures, d'un meilleur suivi. Que la solution soit achetée, construite ou hybride se décide alors sur le payback, pas sur l'intuition du CTO.

Comparaison sectorielle : construction mécanique, commerce, logistique, automobile

La construction mécanique est tentée par le Build. Les entreprises ont une confiance technique en elles, beaucoup d'ingénieurs, de bonnes données produits et souvent une culture du « faire soi-même ». Chez DMG Mori, Trumpf, Wittenstein ou Festo, cette attitude a du sens pour les fonctions AI proches du produit. Pour un constructeur d'installations de 180 personnes de Haute-Franconie qui veut construire sa propre AI textuelle pour les rapports de service, c'est moins vrai. L'odeur de l'huile hydraulique ne rend pas un modèle NLP propriétaire.

Le commerce et la distribution B2B devraient presque toujours penser Buy-first. Recommandation, Pricing, prévision des stocks, clusters clients, pilotage de campagnes — ce sont des domaines avec de nombreux fournisseurs et beaucoup d'expérience. La différenciation y réside moins dans l'algorithme que dans la qualité des données, la logique d'assortiment, les conditions d'achat et l'exécution commerciale. Un commerçant d'Essen m'a dit en avril 2025 : « Nous voulions reconstruire nous-mêmes la logique d'Amazon. » J'ai demandé : « Pourquoi ne pas d'abord vendre comme Amazon ? » Il n'a pas ri.

La logistique est plus pragmatique. Peut-être parce que chaque point de pourcentage s'y traduit immédiatement en palettes, kilomètres et plannings d'équipes. Fiege, Dachser ou Rhenus travaillent avec des plateformes, des partenaires et leurs propres équipes là où c'est approprié. Buy pour l'optimisation standard, Build ou Co-Build pour les données réseau spéciales et la planification spécifique au client. C'est le sol de l'entrepôt qui décide. Pas le département stratégie.

Les équipementiers automobiles sont entre deux chaises. Ils ont du volume, une pression sur la qualité, des exigences de Traceability et des directives OEM. La Predictive Quality, la maintenance, le contrôle visuel et l'AI de planification sont attractifs. Mais de nombreuses usines ont grandi historiquement, les données OT sont fragmentées, et le comité d'entreprise veut être consulté tôt. Celui qui y lance un Build sans plateforme de données finit dans le marécage des PoC. Je l'ai trop souvent vu.

Exemple pratique : 320 employés, 14 mois, un hybride honnête

Un cas que je peux raconter de manière anonymisée : fabricant de composants du Bade-Wurtemberg, 320 employés, chiffre d'affaires de près de 75 millions d'euros, clients dans la construction mécanique et la technologie médicale. J'y étais en octobre 2024. Au contrôle qualité, ça sentait le nettoyant à l'alcool, sous une lampe LED se trouvaient des pièces fraisées dans des plateaux gris. Sabine, responsable qualité, a dit : « Nous perdons du temps parce que nous voyons les erreurs trop tard. »

L'entreprise avait trois idées AI : Vision AI pour le contrôle qualité, Forecasting aux achats, assistance aux offres pour pièces spéciales. Auparavant, on aurait probablement lancé trois PoC. Pas cette fois. Le directeur a passé chaque idée à travers la matrice. Vision AI : Buy. Forecasting : Buy/Configure. Assistance aux offres : Hybride, car la logique de faisabilité technique et les règles de variantes étaient réellement propres à l'entreprise.

Les chiffres après 14 mois : le pilote Vision AI pour deux familles de pièces a coûté environ 210.000 €, incluant caméra, éclairage, intégrateur et formation. Le passage de défauts a chuté de 28 %, les retouches de 11 %. Le Forecasting a été introduit via un module du partenaire ERP existant plus un pipeline de données externe, coût environ 95.000 € ; la Forecast Accuracy a augmenté de 6 points de pourcentage pour les pièces A. L'assistance aux offres a coûté plus cher : environ 380.000 €, car le CPQ, les règles proches de la CAO et les historiques de prix ont été intégrés. En revanche, le temps de traitement moyen des offres complexes est passé de 9,5 à 6,8 jours ouvrables.

Plus importante que les chiffres isolés était la gouvernance. Il y avait un Product Owner par Use Case, une revue mensuelle des KPI, des critères d'arrêt clairs et un petit noyau de données : un Data Engineer, une Analytics Engineer, un architecte externe pendant six mois. Pas de laboratoire AI avec des poufs. Pas de cirque de l'innovation. Juste du travail.

Amplifa ICP Playbook — Playbook pratique pour définir proprement les clients cibles, les sources de données et les priorités avant que l'AI dans la vente ou la génération de leads ne brûle de l'argent.

FAQ : Quand une PME devrait-elle construire elle-même son AI ?

Une PME devrait construire elle-même son AI lorsque trois conditions sont remplies simultanément : la fonction crée une différenciation chez le client, les données nécessaires sont propriétaires et fiables, et l'entreprise peut financer l'exploitation, le monitoring et le développement continu. S'il manque une de ces conditions, je n'autoriserais le Build qu'avec un partenaire et une ligne d'arrêt stricte. Un exemple : le diagnostic d'état intelligent pour ses propres machines avec des données de capteurs exclusives peut justifier le Build. Un chatbot standard pour les demandes de service, non.

FAQ : Quelle est la meilleure stratégie AI pour 50 à 500 employés ?

Pour les entreprises de 50 à 500 employés, une stratégie hybride Buy-first est généralement le meilleur choix. Logiciel standard pour les Use Cases Commodity, propre logique métier pour les processus différenciateurs, petite équipe interne centrale pour les données et la responsabilité produit. Cela semble moins héroïque que « nous construisons notre propre plateforme ». Cela fonctionne plus souvent. Selon BITKOM 2024, l'utilisation productive de l'AI dans les PME allemandes est encore faible ; c'est précisément pour cela que le Time-to-Value compte plus que la fierté technique.

FAQ : Comment éviter le piège du PoC en AI ?

On l'évite avec des critères d'arrêt (Kill-Kriterien) avant même que le premier atelier ne commence. Exemple : si une solution Vision AI ne montre pas une détection au moins 10 % meilleure par rapport au contrôle manuel après douze semaines, elle est arrêtée ou redéfinie. Si une assistance aux offres n'apporte pas de gain de temps mesurable après six mois, elle sort du portefeuille. Cela semble dur. Mais c'est moins cher que 18 mois d'espoir.

Recommandations d'action : 7 étapes pour la décision Build-vs.-Buy

En tant que directeur, CTO ou responsable numérique, je ne commencerais pas par la sélection d'outils. Ni par un atelier AI où, à la fin, 47 Use Cases sont collés sur des post-its sans que personne ne sache qui les paie. Je ferais sept choses. Dans cet ordre précis.

1. Inventoriez les Use Cases AI possibles en production, vente, service et back-office. Inscrivez un indicateur clé à côté de chaque Use Case : rebuts, arrêt, durée d'offre, conversion, stock, coûts de réclamation. Pas d'indicateur, pas de Use Case.
2. Évaluez chaque Use Case avec la matrice 2×2 : potentiel de différenciation contre standardisabilité. Faites l'évaluation en petit comité avec la direction, le métier et l'IT. Pas dans un atelier de 18 personnes.
3. Définissez une règle Buy-first pour les sujets Commodity. Le forecasting, l'analyse de texte standard, l'inspection Vision simple, l'automatisation CRM et la recommandation ne devraient devenir du Build que si une raison commerciale écrite existe.
4. Fixez des critères d'arrêt. Limite de temps, KPI minimum, disponibilité des données, acceptation des utilisateurs. Un PoC sans ligne d'arrêt n'est pas une expérience, mais un risque de coût avec un nom sympathique.
5. Constituez une petite équipe centrale. Pour 50 à 500 employés, cela suffit souvent : un Data Engineer ou Analytics Engineer, un Product Owner fort par Use Case, un architecte IT à temps partiel, des spécialistes externes pour des phases limitées.
6. Intégrez l'AI dans les systèmes existants. Pas de portails AI isolés si les utilisateurs travaillent dans l'ERP, le CRM, le MES, le CPQ ou le système de tickets. L'AI doit apparaître là où le travail se fait de toute façon.
7. Faites un rapport trimestriel sur les applications AI productives, pas sur les PoC. Montrez l'impact business, le taux d'utilisation, les coûts, les risques ouverts. Le CFO devrait comprendre le tableau sans avoir à chercher « Embedding » sur Google.

Produit Amplifa — Automatisation des ventes assistée par AI pour les équipes B2B qui ne veulent pas monter la génération de leads, l'affinage de l'ICP et l'outreach comme un projet de bricolage.

Gouvernance : qui décide, qui est responsable, qui arrête ?

La gouvernance AI sonne comme un truc de grand groupe. Ce n'est pas tout à fait vrai. Les PME en ont justement besoin parce que les circuits sont courts et que les erreurs deviennent vite personnelles. Si une AI recommande de mauvaises validations de qualité, le sujet ne finit pas dans un comité des risques anonyme. Il finit chez Sabine à la qualité, chez Thomas à l'ingénierie et chez le directeur si le client réclame.

Une gouvernance viable pour 50 à 500 employés n'a pas besoin d'être épaisse. Elle nécessite quatre rôles : Business Owner, Product Owner, responsable technique, contrôleur des risques ou de la conformité. Le Business Owner est responsable de l'utilité. Le Product Owner est responsable de l'utilisation et de la roadmap. La technique maintient l'exploitation, la sécurité et le flux de données propres. La conformité vérifie la protection des données, les sujets liés au comité d'entreprise, la pertinence de l'EU AI Act et la capacité d'audit. Quatre noms. Pas « l'IT ».

L'EU AI Act deviendra progressivement plus tangible à partir de 2025 et 2026, en particulier pour les applications à haut risque. De nombreux Use Cases de PME ne tombent pas dans la classe de risque la plus élevée, mais la documentation, la transparence et la responsabilité deviendront plus importantes. Quiconque introduit aujourd'hui une AI dans les décisions de qualité, les processus RH ou les étapes de production liées à la sécurité ne devrait pas attendre que l'auditeur soit dans le hall d'accueil.

La gouvernance décide aussi du Build vs. Buy. En cas de Buy, vous devez vérifier le fournisseur : traitement des données, transparence du modèle, hébergement, concepts d'effacement, accès, logs d'audit. En cas de Build, vous devez pouvoir faire tout cela vous-même. Honnêtement ? Beaucoup d'entreprises de 200 personnes ne le peuvent pas. Ce n'est pas un reproche. C'est un critère de décision.

Stack technique : ce dont les PME ont réellement besoin

Si le Build ou l'Hybride est judicieux, on n'a pas besoin d'un zoo technologique. Je vois trop souvent des schémas d'architecture avec Databricks, Snowflake, Azure ML, MLflow, Airflow, Kafka, Kubernetes et cinq autres logos, alors que l'entreprise envoie encore des fichiers CSV de l'ERP par mail. Ce n'est pas de la stratégie. C'est de la collection de logos.

Pour de nombreuses PME, un stack clair suffit : stockage central des données ou Lakehouse, interfaces stables vers ERP/CRM/MES, un outil MLOps pour le versionnage des modèles et le monitoring, concept de droits, reporting. Azure est fort dans les PME de la région DACH, souvent en raison des contrats Microsoft 365 et des compétences IT existantes. AWS SageMaker, GCP Vertex AI, Databricks, Snowflake, SAP AI Core ou Siemens Industrial Edge peuvent convenir. La question n'est pas de savoir quel logo sonne le plus moderne. La question est de savoir qui l'exploite.

L'Open Source n'est pas un repas gratuit. PyTorch, TensorFlow, scikit-learn, XGBoost, Hugging Face, MLflow — tous de bons outils. Mais quelqu'un doit maintenir les dépendances, vérifier les mises à jour de sécurité, surveiller les modèles, détecter la dérive, réparer les pipelines. Lors d'une équipe de nuit, personne ne se soucie de savoir si l'erreur vient du Feature Store ou de l'interface API. La ligne est à l'arrêt.

En Buy/Configure, le stack est différent. Siemens Industrial Edge ou Insights Hub pour les données industrielles, PTC ThingWorx pour les scénarios proches de l'IoT, SAP AI Core et Joule dans l'environnement ERP, Microsoft Dynamics 365 avec Copilot pour les processus CRM, Celonis pour le Process Mining, o9 ou SAS pour la planification, Cognex ou Landing AI pour la Vision. Ces produits ne résolvent pas tous les problèmes, mais ils donnent une structure. Pour de nombreuses PME, la structure représente déjà la moitié du ROI.

Amplifa pour la stratégie de vente AI — Pour les entreprises B2B de taille moyenne qui souhaitent utiliser l'AI de manière productive dans les ventes, sans avoir à construire d'abord leur propre plateforme d'outreach et de données.

Change Management : l'atelier a son mot à dire

En décembre 2024, j'étais dans une entreprise près de Pforzheim. 160 employés, pièces de précision, beaucoup de travail manuel au contrôle. Un jeune chef de projet expliquait sur un écran une détection de défauts assistée par AI. À côté de moi se tenait un contrôleur, la cinquantaine passée, les mains noires sur le bord des doigts. Il a dit doucement : « Si la machine se trompe, c'est ma faute. » C'était la phrase la plus importante de la journée.

L'introduction de l'AI échoue rarement seulement à cause de la technique. Elle échoue à cause de la responsabilité. Si les gens croient que l'AI leur prend leur travail, leur refile des erreurs ou dévalorise leur expérience, ils ne l'utiliseront pas. Alors le système est contourné, les avertissements sont ignorés, les données sont mal entretenues. Le Change Management ne signifie pas accrocher des affiches. Cela signifie clarifier proprement les rôles, la responsabilité et l'utilité.

Pour la Vision AI dans l'assurance qualité, il doit être clair : l'AI valide-t-elle ou recommande-t-elle ? Qui décide dans les cas limites ? Comment les faux négatifs sont-ils traités ? Comment le feedback des contrôleurs alimente-t-il le modèle ? Pour l'assistance aux offres dans la vente, il doit être clair : l'AI peut-elle suggérer des prix ? Qui vérifie les remises ? Quelles déclarations aux clients sont taboues ? Ces questions ne sont pas des freins. Ce sont des conditions d'exploitation.

Le comité d'entreprise doit être impliqué tôt, pas après le pilote. Surtout pour l'AI dans la mesure de la performance, la planification des équipes, les RH ou les systèmes d'assistance avec données d'utilisation. Je connais des entreprises qui ont perdu trois mois parce qu'elles croyaient que la participation était un acte formel. Ce n'était pas le cas. C'était le véritable déploiement.

Ce que j'attends pour 2026 : moins de théâtre de PoC, plus de sélection rigoureuse

Ma prévision est tranchée : d'ici fin 2026, de nombreuses PME réduiront de moitié leurs portefeuilles AI. Non pas parce que l'AI déçoit. Mais parce que les listes de projets de 2023 et 2024 étaient trop larges, trop techniques et trop mal calculées. Le CFO demandera quelles applications tournent de manière productive. Les ventes demanderont pourquoi l'assistant d'offre n'est pas encore dans le CRM. La production demandera pourquoi le pilote ne fonctionne que sur la ligne 3. Alors, on fera le tri.

Dans le même temps, les bonnes entreprises iront plus vite. Elles ne poursuivront pas 30 Use Cases, mais cinq. Elles prendront des logiciels standards là où ils suffisent, et développeront leur propre savoir-faire là où cela fait mal si le concurrent l'a aussi. Elles ne vont pas « faire de l'AI ». Elles vont réduire les rebuts, accélérer les offres, augmenter le chiffre d'affaires de service, réduire les stocks. C'est un autre ton.

Le CTO de SAP, Klaus Müller, a souligné publiquement à plusieurs reprises l'intégration de l'AI générative dans la Business Suite. Le message pour les PME est clair : tous les clients ne doivent pas construire leurs propres Foundation Models. Beaucoup doivent consommer, intégrer, contrôler l'AI. Je considère cela comme sain. Quiconque croit encore en 2026 qu'une entreprise de 250 personnes doit d'abord fonder son propre lab AI avant d'en voir l'utilité confond PME et institut de recherche.

Au final, reste la scène de Gütersloh. Thomas, le CTO avec son plan à 1,2 million d'euros, m'a rappelé deux semaines après notre entretien. Ils avaient arrêté l'idée de plateforme, lancé deux pilotes Buy et conservé un seul Use Case hybride pour leur logique machine. « Ça semble moins visionnaire », a-t-il dit. En arrière-plan, j'entendais à nouveau le bip du chariot élévateur. C'était peut-être précisément cela, le progrès.