Stratégie IA : Build vs. Buy dans les PME

KI-Strategie · 23. Mai 2026 · Mohsen Ghulami

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

Il y a trois semaines, j'étais à Gütersloh, dans une salle de réunion qui sentait le café filtre et le plastique chaud. Thomas, CTO d'un fabricant de machines de 280 personnes, m'a tendu son iPad et m'a dit : « Nous allons construire notre propre plateforme d'IA. » Dans la cour, un chariot élévateur reculait en bipant, à l'intérieur, une diapositive PowerPoint avec le logo Azure, un serpent Python et un budget de 1,2 million d'euros clignotait. Ma première question n'était pas technique, mais brutalement simple : Est-ce vraiment une stratégie d'IA — 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 se transforment en activité de service. J'ai vu chez de plus petits sous-traitants sur l'Alb souabe comment une seule exportation MES manquante arrête un projet d'IA entier. Et j'ai vu suffisamment de directeurs financiers serrer les lèvres au mot « développement interne », comme s'ils avaient mordu dans un citron.

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

Pourquoi la stratégie IA devient une affaire de 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 avec six centres d'usinage DMG Mori. Le bruit était ce chant métallique dur que l'on connaît des ateliers où personne ne parle de l'avenir, car la commande doit être expédiée avant vendredi. « Nous avons quatre PoC d'IA », a dit Andrea. « Aucun ne fonctionne en production. »

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

Les chiffres confirment cette observation. Selon l'étude Bitkom 2024, environ 15 à 20 % des entreprises allemandes utilisent l'IA de manière productive ; pour les entreprises de 100 à 499 employés, le taux est plutôt dans la fourchette inférieure, environ 10 à 15 %. BCG et VDMA ont constaté en 2023 dans l'ingénierie mécanique un schéma que j'entends constamment dans mes conversations : plus de 60 % expérimentent des PoC d'IA, mais moins de 15 % ont des applications à grande échelle dans l'entreprise. Donc : beaucoup de pilotes, peu d'opérations.

Ce n'est pas une loi naturelle allemande. C'est souvent une mauvaise prise de décision. Les PME traitent trop souvent l'IA comme une acquisition technologique et trop rarement comme une question de création de valeur. Dans une entreprise de 180 employés d'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 IA dans les PME : ce que Build vs. Buy signifie vraiment

Build ne signifie pas que trois Data Scientists entraînent un modèle de fondation dans un sous-sol. Enfin, presque jamais. Build signifie généralement pour les PME : des pipelines de données propres, des modèles propres ou du moins une logique de domaine propre, des processus MLOps propres, un monitoring propre, une responsabilité propre. Le fournisseur peut fournir l'infrastructure cloud, mais l'entreprise supporte le risque produit et opérationnel.

Buy ne signifie pas que l'on achète un logiciel et que l'on économise 15 % de rebuts le lundi. Ceux qui le croient n'ont jamais vu une interface entre un ancien ERP, une exportation Excel et un contrôle machine. Buy signifie : acheter des logiciels standard, du SaaS ou des composants de plateforme, les configurer, les intégrer, les former, les 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 se situe pas entre le cloud et le on-premise. Elle se situe entre la commodité et la différenciation. La prévision, le NLP standard, la classification d'images, l'optimisation d'itinéraires, l'assistance à la proposition, les moteurs de recommandation simples — il existe des produits utilisables pour cela. L'IA au cœur du produit, comme la sensorique intelligente, la navigation autonome, le contrôle de processus propriétaire ou un algorithme de service qui apprend de 15 ans de données machine — là, Build peut être judicieux. Peut. Pas nécessairement.

PwC et Roland Berger décrivent depuis 2023 un schéma qui apparaît également dans mes conversations : les PME plus petites et moyennes optent majoritairement pour Buy ou Configure, les PME plus grandes choisissent plus souvent l'hybride. L'entreprise de 300 personnes achète plutôt Microsoft, SAP, Cognex, Celonis, o9, PTC ou un fournisseur spécialisé. Le fournisseur de 3 000 personnes construit peut-être un centre de compétences analytiques et développe là où se trouve la valeur ajoutée. Cela semble banal. Pourtant, c'est constamment ignoré.

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

Au cours des deux dernières années, j'ai discuté à Munich, Stuttgart, Bielefeld et Linz avec des responsables numériques qui gèrent leurs budgets d'IA non pas dans des communiqués de presse, mais dans Excel. Les fourchettes sont étonnamment stables. Un PoC Build dans une PME coûte généralement entre 100 000 et 300 000 euros pour trois à six mois. Jusqu'à ce qu'un MVP soit productif, 300 000 à 800 000 euros sont réalistes, les coûts de personnel interne n'étant pas toujours calculés avec précision. Et c'est là que commence l'auto-illusion.

Car le Data Scientist n'est pas gratuit, juste parce qu'il est déjà sur la masse salariale. L'ingénieur de production qui vérifie les étiquettes huit heures par semaine non plus. L'architecte informatique qui clarifie les autorisations de sécurité, encore moins. Dans une usine près d'Ulm, en février 2025, ça sentait le lubrifiant de refroidissement, tandis que Martin, responsable informatique, me disait : « Nous n'avons dépensé que 180 000 euros en externe. » Deux heures plus tard, il me montrait l'estimation des coûts internes. Avec le travail interne, le projet s'élevait à 520 000 euros.

Buy ou Configure démarre plus bas. Licence pilote plus intégration : souvent 50 000 à 250 000 euros. Déploiement sur plusieurs usines ou départements : 150 000 à 800 000 euros. Les coûts de licence courants pour de nombreux scénarios de PME se situent entre 50 000 et 200 000 euros 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 la troisième année de contrat sait de quoi je parle.

Les taux de réussite sont le véritable coup dur. McKinsey a rapporté dans son State of AI 2023 que seulement environ 20 à 30 % des entreprises obtiennent des avantages financiers significatifs des projets d'IA. Dans la fabrication et les biens industriels, selon mon expérience et les benchmarks de consultants, 50 à 70 % des PoC meurent avant d'atteindre une véritable exploitation. Pour Build, souvent seulement 30 à 40 % réussissent le passage en production. Pour 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 de base dans le modèle.

Build est rentable — mais moins souvent que les présentations de startups ne le prétendent

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, les utilisateurs le touchent, l'indicateur bouge et le chef d'atelier ne parle plus de « ce truc d'IA », mais de son nouvel outil. C'est puissant. Mais 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 machine approfondies, une histoire de plateforme propre avec AXOOM et un écosystème autour de TruConnect. Depuis environ 2017, Trumpf investit continuellement dans les services numériques, la maintenance prédictive et les fonctions Smart Factory. Dans les présentations publiques, Trumpf parle pour certaines installations de 20 à 30 % de temps d'arrêt en moins grâce à la maintenance prédictive. 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 une vision par ordinateur, une navigation, une fusion de capteurs et un logiciel robuste dans le produit physique. Un recommandeur standard du cloud est de peu d'utilité. Kärcher a développé des compétences numériques depuis environ 2018, notamment dans le Digital Hub, et combine le développement interne avec des composants cloud. Ici, Build n'est pas un prestige. L'IA est dans l'appareil, dans le prix, dans le contrat de service.

C'est le point : Build est rentable si l'IA modifie la valeur client ou représente un processus que les concurrents ne peuvent pas simplement copier. Un fabricant de machines-outils avec des milliards de données de capteurs historiques a une situation de départ différente d'un grossiste de 220 personnes qui veut améliorer le cross-selling dans sa boutique en ligne. Ceux qui brouillent ces différences mettent la charrue avant les bœufs.

Nous ne développons en interne que là où nous voyons un avantage concurrentiel clair et où nos connaissances en matière de processus ou de produits sont uniques. Nous achetons les analyses standard et les modèles linguistiques.

— selon un CDO d'un fabricant de machines allemand, entretien Handelsblatt 2024

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

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

À Münster, en novembre 2024, j'ai rencontré un responsable logistique, Ralf, qui avait auparavant participé à des projets de prévision chez Fiege. Nous étions assis dans une cantine, ça sentait la sauce rôtie, et de l'entrepôt venait 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 modules Azure et des solutions partenaires, par exemple pour les prévisions et l'optimisation. Les cas d'utilisation publiés parlent de 2 à 5 % de réduction des stocks et de 3 à 8 % d'amélioration de la précision des prévisions, selon le domaine.

C'est la réalité des PME, juste un peu plus grande. Une prévision est rarement unique. Une optimisation d'itinéraire non plus. Un contrôle qualité basé sur l'image avec une classe d'erreur définie est techniquement exigeant, mais souvent pas une raison de créer sa propre équipe de 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 l'Allemagne illustre clairement la logique. Fabricant de machines, 800 employés, inspection visuelle manuelle, manque de personnel, forte pression de retouche. L'entreprise a acheté un système de vision IA commercial au lieu de le développer en interne. Investissement initial : environ 350 000 euros 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 environ 30 % plus bas, amortissement en moins de 18 mois. Pas de prix de l'innovation. Mais de l'argent.

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

La deuxième vérité : 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 loué après dix sous-locataires : des adaptateurs partout, personne ne sait plus à 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 liés à l'IA dans les ventes, le service et la planification. Avec les interfaces, le conseil et les administrateurs internes, les coûts annuels se sont soudainement élevés à 310 000 euros. Bénéfice ? Difficilement mesurable. « Nous avons maintenant des tableaux de bord », a déclaré le directeur des ventes. J'ai eu pitié de lui.

La plus grande erreur de Buy est la foi aveugle dans les fonctionnalités. Une démo logicielle montre toujours des données propres. Toujours. En exploitation réelle, il y a des doublons de clients, des hiérarchies d'articles manquantes, des modèles de quarts de travail différents et un champ ERP appelé « Divers » qui contient depuis 2009 tout ce que personne n'a voulu 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 du stockage de données, de la logique de modèle, de l'interface utilisateur et de l'intégration de processus, l'entreprise devient dépendante. Cela peut être acceptable si le cas d'utilisation est une commodité et que le fournisseur livre de manière stable. Pour les processus critiques, il faut être plus prudent. Exportation de données, capacité d'audit, coûts de mise à l'échelle, scénario de sortie — des sujets ennuyeux, oui. C'est précisément pourquoi ils sont lus trop tard.

Où les projets Build meurent dans les PME

Il y a une scène qui se répète. Salle de réunion, tapis gris, tableau blanc avec des restes d'un atelier, quelque part il y a encore écrit « Priorisation des cas d'utilisation ». Dans la pièce, l'IT, le département métier et un consultant externe sont assis. Après 14 mois de projet, quelqu'un demande : « Qui est le Product Owner, au fait ? » Puis le silence se fait. J'ai vécu cela à Cologne, Nuremberg et St. Gallen.

La première cause de décès est la qualité des données. Pas sexy, mais mortelle. Un fournisseur automobile d'environ 3 000 employés a lancé sur trois ans plusieurs PoC de maintenance prédictive, en collaboration avec un institut de recherche. Coût : plus d'un million d'euros, temps interne inclus. Tous les pilotes sont restés bloqués sur des installations individuelles. L'OT et l'IT étaient séparées, 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 de panne. Après un changement de direction informatique, une plateforme standard a été adoptée. Neuf mois plus tard, les premiers cas d'utilisation productifs étaient en cours, après 18 mois, environ 15 % de pannes imprévues en moins ont été signalées sur les installations sélectionnées.

La deuxième cause de décès est la fausse fierté. Un distributeur B2B de la région DACH avec environ 1 200 employés voulait construire son propre moteur de recommandation, également pour réduire la dépendance vis-à-vis des 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, les performances après des tests internes n'étaient que de 60 à 70 % d'un recommandeur cloud standard. Le projet a été arrêté, la solution SaaS est quand même arrivée. Mais plus tard et plus cher.

La troisième cause de décès est le manque de pensée produit. L'IA 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 planifie le réentraînement, personne ne se sent responsable des fausses alertes. Après six mois, le chef d'équipe dit : « Ce truc déraille. » Et l'acceptation est déjà perdue.

MLOps n'est pas un mot à la mode ici, mais un travail de concierge pour les modèles. Surveillance, versioning des données, processus de validation, rollback, responsabilités, piste d'audit. Cela semble sec. Et ça l'est. Mais sans ces routines, l'IA devient un logiciel jetable. On construit, on montre, on oublie.

La matrice Build-vs.-Buy pour une stratégie IA fiable

J'aime utiliser une matrice 2x2 simple dans mes conversations. Pas de magie. Sur l'axe des X se trouve le potentiel de différenciation : cette fonction d'IA nous rend-elle plus difficilement copiable sur le marché ? Sur l'axe des Y se trouve la standardisation : 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 échouent.

Quadrant un : fort potentiel de différenciation, faible standardisation. Ici, on peut sérieusement envisager Build ou Co-Build. Exemples : IA dans un dispositif médical avec une sensorique spéciale, 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'IA est alors proche du produit ou du secret de processus.

Quadrant deux : faible potentiel de différenciation, forte standardisation. Acheter. Point. Prévision standard, classification de texte dans le service client, chatbots simples, vérification des dépenses, scoring de leads, inspection d'images avec des défauts connus. Ceux qui prônent le Build ici devraient mettre sur la table les coûts d'opportunité. Pas sous forme de diapositive. Mais en euros.

Quadrant trois : fort potentiel de différenciation, forte standardisation. C'est le domaine hybride passionnant. Un LLM peut générer des ébauches d'offres, mais la logique de produit propre, 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 des interfaces, mais le cerveau commercial réside dans le modèle de données propre. C'est précisément là que les PME devraient développer leurs compétences.

Quadrant quatre : faible potentiel de différenciation, faible standardisation. Généralement un signal d'avertissement. Si quelque chose n'est ni stratégiquement important ni facilement achetable, pourquoi le faire ? Parce qu'un chef de service le veut ? Parce qu'un programme de subventions fait signe ? L'argent des subventions n'est pas un business case. Il n'y a pas de discussion possible.

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

En juin 2025, un directeur général de Ravensburg m'a appelé. 120 employés, construction de machines spéciales, un EBIT correct, mais une informatique légère. Il a demandé : « Combien nous coûte une IA pour l'automatisation des offres ? » J'ai répondu : « Combien coûte une offre aujourd'hui ? » Silence. Puis un feuilletage. Puis le chiffre : environ 1 800 euros de travail interne pour les machines complexes, lorsque 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 IA 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, cela se décide alors par le retour sur investissement, et non par l'intuition du CTO.

Comparaison sectorielle : Ingénierie mécanique, commerce, logistique, automobile

L'ingénierie mécanique est tentante pour le Build. Les entreprises ont une confiance technique en elles, de nombreux ingénieurs, de bonnes données produit et souvent une culture du « faire soi-même ». Chez DMG Mori, Trumpf, Wittenstein ou Festo, cette attitude a du sens pour les fonctions d'IA proches du produit. Pour un fabricant d'installations de 180 personnes de Haute-Franconie qui veut construire sa propre IA textuelle pour les rapports de service, plutôt non. 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, tarification, prévision des stocks, clusters de clients, contrôle des campagnes — ce sont des domaines avec de nombreux fournisseurs et beaucoup d'expérience. La différenciation 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 des ventes. Un commerçant d'Essen m'a dit en avril 2025 : « Nous voulions reproduire la logique d'Amazon nous-mêmes. » 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 se traduit immédiatement en palettes, kilomètres et plannings. Fiege, Dachser ou Rhenus travaillent avec des plateformes, des partenaires et leurs propres équipes là où cela convient. Buy pour l'optimisation standard, Build ou Co-Build pour les données réseau spéciales et la planification spécifique au client. Le sol de l'entrepôt décide. Pas le département stratégie.

Les fournisseurs automobiles sont entre deux chaises. Ils ont du volume, une pression sur la qualité, des exigences de traçabilité et des spécifications OEM. La qualité prédictive, la maintenance, l'inspection visuelle et l'IA de planification sont attrayantes. Mais de nombreuses usines ont grandi historiquement, les données OT sont fragmentées, et le comité d'entreprise veut être consulté tôt. Ceux qui commencent Build sans plateforme de données se retrouvent dans le bourbier des PoC. Je l'ai vu trop souvent.

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

Un cas que je peux raconter anonymement : fabricant de composants du Bade-Wurtemberg, 320 employés, chiffre d'affaires d'environ 75 millions d'euros, clients de l'ingénierie mécanique et de la technologie médicale. J'y étais en octobre 2024. Au contrôle qualité, ça sentait le nettoyant à l'alcool, sous une lampe LED, des pièces fraisées étaient posé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 d'IA : Vision AI pour le contrôle qualité, prévision dans les achats, assistance à la proposition pour les pièces spéciales. Auparavant, on aurait probablement lancé trois PoC. Cette fois, non. Le directeur général a fait passer chaque idée par la matrice. Vision AI : Buy. Prévision : Buy/Configure. Assistance à la proposition : Hybride, car la logique de faisabilité technique et les règles de variantes étaient vraiment 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 euros, y compris la caméra, l'éclairage, l'intégrateur et la formation. Le taux de défauts passés inaperçus a diminué de 28 %, les retouches de 11 %. La prévision a été introduite via un module du partenaire ERP existant plus un pipeline de données externe, coût environ 95 000 euros ; la précision des prévisions a augmenté de 6 points de pourcentage pour les pièces A. L'assistance à la proposition a coûté plus cher : environ 380 000 euros, car le CPQ, les règles proches du CAD et les historiques de prix ont été intégrés. En contrepartie, le temps de traitement moyen des offres complexes est passé de 9,5 à 6,8 jours ouvrables.

Plus important que les chiffres individuels était la gouvernance. Il y avait un Product Owner par cas d'utilisation, une vue 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 d'IA avec des poufs. Pas de cirque de l'innovation. Juste du travail.

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

FAQ : Quand une PME devrait-elle construire sa propre IA ?

Une PME devrait construire sa propre IA si trois conditions sont remplies simultanément : la fonction crée une différenciation pour 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. Si l'une de ces conditions manque, je n'autoriserais le Build qu'avec un partenaire et une ligne d'arrêt stricte. Un exemple : le diagnostic intelligent de l'état des machines propres 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 IA 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 cas d'utilisation courants, logique de domaine propre pour les processus différenciants, petite équipe interne pour les données et la responsabilité du 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'IA dans les PME allemandes est encore faible ; c'est précisément pourquoi le Time-to-Value compte plus que la fierté technique.

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

On l'évite avec des critères d'arrêt avant le premier atelier. Exemple : si une solution Vision AI ne montre pas une amélioration d'au moins 10 % de la reconnaissance par rapport à un échantillon manuel après douze semaines, elle est arrêtée ou redéfinie. Si une assistance à la proposition n'apporte pas de gain de temps mesurable après six mois, elle est retirée 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 général, CTO ou responsable numérique, je ne commencerais pas par la sélection d'outils. Ni par un atelier IA où, à la fin, 47 cas d'utilisation sont collés sur des post-it et personne ne sait qui les paie. Je ferais sept choses. Dans cet ordre précis.

1. Inventoriez les cas d'utilisation potentiels de l'IA dans la production, les ventes, le service et le back-office. Notez un indicateur clé pour chaque cas d'utilisation : rebuts, temps d'arrêt, durée de l'offre, conversion, stock, coûts de réclamation. Pas de cas d'utilisation sans indicateur clé.
2. Évaluez chaque cas d'utilisation avec la matrice 2x2 : potentiel de différenciation par rapport à la standardisation. Faites l'évaluation en petit comité avec la direction, le département métier et l'IT. Pas dans un atelier de 18 personnes.
3. Définissez une règle Buy-first pour les sujets courants. La prévision, l'analyse de texte standard, l'inspection visuelle simple, l'automatisation du CRM et la recommandation ne devraient être Build que s'il existe une raison commerciale écrite.
4. Établissez des critères d'arrêt. Limite de temps, KPI minimum, disponibilité des données, acceptation par l'utilisateur. Un PoC sans ligne d'arrêt n'est pas une expérience, mais un risque de coût avec un nom amical.
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 cas d'utilisation, un architecte IT à temps partiel, des spécialistes externes pour des phases limitées.
6. Intégrez l'IA dans les systèmes existants. Pas de portails IA isolés si les utilisateurs travaillent dans l'ERP, le CRM, le MES, le CPQ ou le système de tickets. L'IA doit apparaître là où le travail se fait de toute façon.
7. Rendez compte trimestriellement des applications d'IA productives, et non des PoC. Montrez l'impact commercial, le taux d'utilisation, les coûts, les risques ouverts. Le directeur financier doit comprendre le tableau sans avoir à chercher « embedding » sur Google.

Produit Amplifa Automatisation des ventes basée sur l'IA pour les équipes B2B qui ne veulent pas mettre en place la génération de leads, l'affinement de l'ICP et l'outreach comme un projet de bricolage.

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

La gouvernance de l'IA sonne comme une entreprise. Ce n'est pas tout à fait vrai. Les PME en particulier en ont besoin, car les chemins sont courts et les erreurs deviennent rapidement personnelles. Si une IA recommande de fausses validations de qualité, le problème ne se retrouve pas dans un comité de risque anonyme. Il se retrouve chez Sabine au contrôle qualité, chez Thomas à l'ingénierie et chez le directeur général si le client se plaint.

Une gouvernance utilisable pour 50 à 500 employés n'a pas besoin d'être lourde. Elle nécessite quatre rôles : Business Owner, Product Owner, responsable technique, vérificateur de risques ou de conformité. Le Business Owner est responsable du bénéfice. Le Product Owner est responsable de l'utilisation et de la feuille de route. La technique assure le bon fonctionnement, la sécurité et le flux de données. La conformité vérifie la protection des données, les questions du 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 perceptible à partir de 2025 et 2026, en particulier pour les applications à haut risque. De nombreux cas d'utilisation des PME ne relèvent pas de la classe de risque la plus élevée, mais la documentation, la transparence et la responsabilité deviendront plus importantes. Ceux qui introduisent aujourd'hui une IA dans les décisions de qualité, les processus RH ou les étapes de production liées à la sécurité ne devraient pas attendre que l'auditeur soit dans le hall d'entrée.

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

Pile technologique : ce dont les PME ont vraiment besoin

Si le Build ou l'Hybride est judicieux, il n'est pas nécessaire d'avoir un zoo technologique. Je vois trop souvent des architectures 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 e-mail. Ce n'est pas une stratégie. C'est une collection de logos.

Pour de nombreuses PME, une pile claire suffit : stockage centralisé des données ou Lakehouse, interfaces stables vers ERP/CRM/MES, un outil MLOps pour le versioning et le monitoring des modèles, un concept de droits, un reporting. Azure est fort dans les PME 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 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 gérer les dépendances, vérifier les mises à jour de sécurité, surveiller les modèles, détecter la dérive, réparer les pipelines. En équipe de nuit, personne ne se soucie de savoir si l'erreur vient du Feature Store ou de l'interface PLC. La ligne est arrêtée.

Pour Buy/Configure, la pile est différente. Siemens Industrial Edge ou Insights Hub pour les données industrielles, PTC ThingWorx pour les scénarios 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 est déjà la moitié du ROI.

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

Gestion du changement : L'atelier décide aussi

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 pour l'inspection. Un jeune chef de projet expliquait sur un moniteur une détection d'erreurs assistée par IA. À côté de moi se tenait un inspecteur, peut-être la cinquantaine, les mains noires au bout des doigts. Il a dit doucement : « Si la boîte est mal placée, c'est ma faute. » C'était la phrase la plus importante de la journée.

L'introduction de l'IA échoue rarement uniquement à cause de la technologie. Elle échoue à cause de la responsabilité. Si les gens croient que l'IA leur enlève du travail, leur attribue des erreurs ou dévalorise leur savoir-faire, ils ne l'utilisent pas. Alors le système est contourné, les avertissements sont ignorés, les données sont mal gérées. La gestion du changement ne signifie pas afficher des affiches. Cela signifie clarifier clairement les rôles, la responsabilité et les avantages.

Pour la Vision AI dans le contrôle qualité, il doit être clair : l'IA valide-t-elle ou recommande-t-elle ? Qui décide dans les cas limites ? Comment les faux négatifs sont-ils traités ? Comment les retours des inspecteurs sont-ils intégrés au modèle ? Pour l'assistance à la proposition dans les ventes, il doit être clair : l'IA 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'IA dans la mesure des performances, la planification des quarts de travail, les RH ou les systèmes d'assistance avec des données d'utilisation. Je connais des entreprises qui ont perdu trois mois parce qu'elles croyaient que la participation était une formalité. Ce n'était pas le cas. C'était le véritable déploiement.

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

Ma prévision est tranchante : d'ici fin 2026, de nombreuses PME réduiront de moitié leurs portefeuilles d'IA. Non pas parce que l'IA déçoit. Mais parce que les listes de projets de 2023 et 2024 étaient trop larges, trop techniques et mal calculées. Le directeur financier demandera quelles applications sont productives. Les ventes demanderont pourquoi l'assistant de proposition 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.

En même temps, les bonnes entreprises iront plus vite. Elles ne poursuivront pas 30 cas d'utilisation, mais cinq. Elles utiliseront des logiciels standard là où ils suffisent, et développeront leur propre savoir-faire là où cela fait mal si le concurrent l'a aussi. Elles ne feront pas de « l'IA ». Elles réduiront les rebuts, accéléreront les offres, augmenteront les revenus de service, réduiront les stocks. C'est un autre ton.

Le CTO de SAP, Jürgen Müller, a souligné publiquement à plusieurs reprises l'intégration de l'IA générative dans la Business Suite. Le message pour les PME est clair : tous les clients ne doivent pas construire leurs propres modèles de fondation. Beaucoup doivent consommer, intégrer, contrôler l'IA. Je pense que c'est sain. Ceux qui croient encore en 2026 qu'une entreprise de 250 personnes doit d'abord créer son propre laboratoire d'IA avant d'en voir les avantages confondent PME et institut de recherche.

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