L'ERP dans le Mittelstand : comment un logiciel sur mesure étend votre ERP

L'agenda informatique de 2026 se lit comme un problème insoluble.

D'un côté, la liste des obligations. En Allemagne, l'émission de factures électroniques devient obligatoire en B2B à partir du 1er janvier 2027, un an plus tard pour les petites entreprises. La loi de transposition de NIS2 est en vigueur depuis décembre 2025 et a élargi le cercle des entreprises surveillées d'environ 4 500 à quelque 29 500, la production industrielle étant expressément incluse, sans période transitoire. Le règlement européen sur l'IA est applicable depuis le 2 août 2026. Qui exploite SAP ECC bénéficie de la maintenance standard jusqu'à fin 2027, puis d'une prolongation payante jusqu'en 2030.

De l'autre côté, le budget. Selon l'étude Lünendonk sur l'agenda des DSI, seuls 55 pour cent des décideurs informatiques s'attendent à une hausse de leur budget pour 2026. Un an plus tôt, ils étaient encore 79 pour cent. Dans le même temps, 91 pour cent veulent investir davantage dans la sécurité et 80 pour cent dans la modernisation informatique, afin de réduire la dette technique.

Et entre les deux, rarement nommé, le vrai sujet : le processus qui distingue votre entreprise de la concurrence tourne encore dans un fichier Excel sur un lecteur réseau. Non pas parce que personne ne l'a remarqué, mais parce que l'ERP ne pouvait pas le représenter et qu'il n'y a jamais eu de place pour un projet dédié.

La réponse est rarement un ERP plus gros et presque jamais une solution isolée de plus. C'est un cœur ERP allégé, complété par quelques applications propres et ciblées sur des interfaces propres. Ce n'est pas une attaque contre votre éditeur d'ERP. C'est précisément l'architecture que les éditeurs recommandent eux-mêmes.

Qu'est-ce qu'un logiciel ERP, et ce qu'il n'est pas

Brièvement, car le terme est si employé qu'il a perdu sa netteté.

Un système ERP (Enterprise Resource Planning) est la gestion centralisée des ressources économiques de votre entreprise sur un modèle de données commun. Clients, articles, commandes, stocks, pièces comptables, coûts et comptes se trouvent en un seul endroit, et les modules achats, ventes, entrepôt, production, finance et ressources humaines travaillent tous sur ces données. C'est le sens véritable d'un logiciel ERP, et il ne réside pas dans la liste de fonctions mais dans cette seule phrase : une vérité, plusieurs vues.

Cela dit aussi ce qu'un ERP n'est pas. Ce n'est pas une boîte à outils dans laquelle chaque processus de votre maison trouve sa place. C'est un système de référence pour les opérations standard : des opérations qui se déroulent partout à peu près de la même manière, qui sont réglementées, qui doivent être documentées et auditables, et par lesquelles vous ne vous distinguez de personne.

Cette distinction est l'axe autour duquel tourne tout le reste de cet article :

• Les systèmes de référence détiennent les données faisant foi. Comptabilité, stocks, pièces, données de base. Ici, le standard gagne, toujours.
• Les systèmes de différenciation représentent la façon dont votre entreprise travaille. L'ordre dans lequel vous lancez les commandes. La manière dont vous contrôlez. La règle selon laquelle vos achats planifient. Ici, le standard perd, parce que ce standard n'existe pas.

Un système ERP qui tente d'être les deux devient mauvais aux deux extrémités.

L'ERP allégé comme fondation, pas comme compromis

Il existe une lecture du « logiciel sur mesure » que je tiens pour fausse : celle où l'ERP est le problème. Il ne l'est pas. Pour tout ce qui est standardisé et réglementé, un système ERP bien déployé est la solution la moins chère et la plus durable que vous puissiez acheter. Comptabilité, fiscalité, paie, gestion des stocks, flux documentaire, et à partir de 2027 la facturation électronique : vous ne voulez ni le construire ni le maintenir vous-même.

Le mot décisif est allégé. Un ERP allégé est un ERP qui tourne au plus près du standard possible. C'est exactement là que se trouve l'argent, en pratique.

Car toute modification du cœur est un crédit que vous remboursez à la prochaine montée de version. Et pour beaucoup, cette montée de version arrive. Chez les clients SAP, la maintenance standard d'ECC 6.0 s'achève le 31 décembre 2027, prolongeable jusqu'en 2030 contre une majoration de deux points de pourcentage sur les frais de maintenance. Un passage honnête à S/4HANA prend dix-huit à trente mois dans une entreprise de taille intermédiaire, et selon les enquêtes environ 60 pour cent de ces migrations manquent leur objectif de budget, de calendrier ou de qualité. Je ne cite SAP ici qu'à titre d'exemple, parce que l'échéance est bien datée. La mécanique est la même avec tout ERP : ce que vous avez construit dans le cœur, vous le migrez avec, vous le retestez et vous le payez deux fois.

Les éditeurs le disent désormais eux-mêmes. SAP appelle cela Clean Core, Gartner appelle cela Composable ERP, successeur du « Postmodern ERP » formulé en 2013. L'énoncé central est identique dans toutes les variantes : gardez le cœur proche du standard et étendez-le à côté, via des interfaces, plutôt qu'à l'intérieur.

Et les utilisateurs suivent. Dans le rapport d'investissement DSAG 2026, la SAP Business Technology Platform est la solution SaaS la plus demandée, avec 39 pour cent d'intentions d'investissement élevées et moyennes, contre 33 pour cent en 2024. Son usage est remarquablement net : 45 pour cent citent des tâches d'intégration complexes, 38 pour cent l'analyse pilotée par les données. La conclusion du rapport est que les décisions d'investissement sont guidées non par des visions, mais par la faisabilité, la rentabilité et la capacité d'intégration.

Autrement dit : le marché dépense en ce moment beaucoup d'argent pour déplacer les extensions hors du cœur ERP, vers ses interfaces.

Où l'ERP atteint ses limites dans le Mittelstand

Un produit standard présuppose un processus clairement défini et idéal-typique. Le Mittelstand vit de processus qui se sont développés au fil des années, qui résident dans les têtes plutôt que dans des manuels, et qui font exactement ce qui fait le succès de cette entreprise précise. Plus de 70 pour cent des entreprises de taille intermédiaire n'ont pas entièrement documenté leurs processus de bout en bout. Ce n'est pas de la négligence, c'est la nature même de la chose.

Nous avons traité cette contradiction en détail ailleurs, d'où ce simple renvoi : Une PME peut-elle vraiment développer un logiciel sur mesure pour le Mittelstand ?

Plus intéressant est de savoir où la limite passe de façon fiable dans le Mittelstand. D'après notre expérience, presque toujours aux quatre mêmes endroits :

Spécificités de la production et de l'atelier. L'ordonnancement fin à la machine, les séquences de réglage, les cas particuliers que chaque chef d'atelier connaît et qu'aucun module ne prévoit.

Coordination entre sociétés et entre sites. Dès que plusieurs entités sont simultanément fournisseur et client l'une de l'autre, la notion d'« une » commande selon l'ERP s'arrête.

Flux de contrôle et de qualité. Qui contrôle quoi, dans quel ordre, avec quelle validation, avec quelle preuve. Presque aucune entreprise ne procède comme sa voisine, et presque aucun résultat de contrôle n'entre dans un champ standard.

Chiffrage, configuration et planification. Partout où c'est une règle qui décide, et non un formulaire. Combien commandons-nous, comment chiffrons-nous une fabrication spéciale, quelle variante est même réalisable.

Comment savoir que vous êtes à cette limite, sans projet d'analyse :

• Une liste est tenue à côté du système, et c'est la liste qui a raison.
• La même information est saisie deux fois, en deux endroits, par deux personnes.
• Il existe un chiffre de référence auquel tout le monde croit, et il est produit dans un tableur.
• Une opération attend régulièrement une personne, et non une validation.
• À la question de savoir pourquoi un résultat est ainsi, quelqu'un répond par une règle d'expérience, non par une logique du système.
• Lors de la dernière mise à jour de l'ERP, quelque chose que vous aviez vous-mêmes ajouté s'est cassé.

À quoi ressemble un tel point dans la réalité, nous l'avons consigné sur un projet concret dans lequel les achats ne croyaient plus à leur propre planification des commandes : Anatomie d'une optimisation de processus.

Deux issues à cette lacune, et une seule passe à l'échelle

Une fois la lacune reconnue, il y a deux réactions. Toutes deux paraissent pragmatiques, et elles diffèrent d'un ordre de grandeur en coûts consécutifs.

Voie une : la solution isolée. On achète un outil spécialisé pour exactement ce cas. Il traite ce cas vraiment bien. Mais il apporte aussi avec lui : sa propre liste de clients, son propre référentiel d'articles, sa propre gestion des utilisateurs, sa propre notion d'habilitations, son propre contrat de maintenance, son propre risque de mise à jour et, depuis NIS2, sa propre part dans votre politique de sécurité.

Le coûteux là-dedans n'est pas le premier outil. C'est le troisième. Car les coûts ne croissent pas avec le nombre de systèmes, mais avec le nombre de liaisons entre eux, et ce nombre croît nettement plus vite. S'y ajoute la part qui ne figure sur aucune facture : à partir de deux copies d'une vérité de données de base, il n'est plus établi laquelle fait foi. À partir de là, votre organisation ne discute plus de décisions, elle discute de chiffres.

C'est exactement ce schéma que décrit de l'intérieur l'enquête DIHK sur la numérisation 2026, à laquelle 4 686 entreprises ont participé : comme principaux obstacles à la numérisation, les entreprises citent le temps (58 pour cent) et la complexité (56 pour cent), loin devant le manque de spécialistes informatiques (29 pour cent). Ce n'est pas l'incapacité qui freine, c'est la gestion de l'existant.

Voie deux : l'extension. On construit la logique métier manquante comme une application propre, mais sans référentiel propre pour ce que l'ERP gère déjà. Elle lit les clients, les articles et les commandes dans l'ERP au lieu de les tenir à jour. Elle utilise la connexion et les rôles qui existent déjà dans la maison. Elle réécrit son résultat là où il appartient.

La différence entre les deux voies n'est donc pas « acheter ou construire ». Vous pouvez acheter un outil qui se raccorde proprement à votre ERP, et vous pouvez construire une application propre qui traîne malgré tout son propre référentiel clients.

La différence est de savoir si, ensuite, un seul endroit dans la maison dit encore de façon contraignante qui est ce client et combien coûte cet article. Ou deux.

Intégration des données : dupliquer ou consolider ?

Nous voici à la question sur laquelle de tels projets se tranchent techniquement. Et comme beaucoup de vocabulaire s'y mélange, d'abord deux termes qu'il vaut la peine de distinguer :

• Le système de référence est l'endroit où un objet de données naît et fait foi. Il y en a exactement un par objet.
• Le point de consolidation est l'endroit où les données de plusieurs systèmes convergent pour l'analyse. Il fait foi pour les analyses et jamais pour les opérations.

Qui confond les deux construit un entrepôt de données dans lequel on finira par réécrire. C'est le début de la fin de la traçabilité.

Sur cette base, il existe quatre modèles, et le choix est une décision métier, non une affaire de goût :

Copier a donc une place légitime, mais étroite : fonctionnement hors ligne, charge de lecture, découplage des fenêtres de maintenance, historique et preuve, ainsi que phases de migration. Ce que copier ne légitime jamais, c'est le confort à l'interface.

Et pour que la décision ne se dilue pas dans le projet, elle appartient à un document qu'un DSI peut exiger avant qu'une ligne de code n'existe. Nous l'appelons la matrice de gouvernance des données. C'est un tableau, il tient sur une page, et il répond à cinq questions par objet de données :

L'effet le plus important de ce tableau est celui qu'on n'attend pas au premier remplissage : une partie des lignes est gérée par l'extension, non par l'ERP. Les résultats de contrôle, les retours machine et les prévisions sont des données pour lesquelles votre ERP n'a pas de champ compétent et ne devrait pas en avoir. Dès que cela est écrit, l'extension n'est plus un appendice mais une composante régulière de votre paysage, avec une responsabilité clairement délimitée.

L'architecture telle qu'un DSI devrait la voir

Commençons par le cas où vous n'avez pas encore besoin d'architecture.

La première application propre peut se raccorder directement à l'ERP. Elle utilise ses interfaces, récupère clients et articles, réécrit son résultat, terminé. Ce n'est pas un pis-aller ni une dette contractée, c'est la bonne décision : construire une couche d'intégration pour une seule liaison serait un effort sans contrepartie.

Le point de basculement, c'est la deuxième extension. Et pour une raison qui paraît anodine sur une diapositive et ne l'est pas en exploitation : ce n'est pas le nombre d'applications qui croît, mais le nombre de liaisons entre elles. Trois extensions qui doivent se connaître mutuellement ne font pas trois liaisons, mais six. S'y ajoute que chacune de ces liaisons contient une fois de plus le même travail : connexion à l'ERP, correspondance des champs, gestion des erreurs, reprise après incident. À la prochaine mise à jour de l'ERP, chacune est reprise et testée séparément.

À partir de là, la couche intermédiaire est rentable. Non parce que l'architecture serait belle, mais parce qu'elle fait ce travail une fois au lieu de six. Au niveau de la direction, cela n'exige pas de diagramme de composants. Cela exige trois bandes et cinq règles.

En haut vos extensions, chacune pour exactement un processus qui vous distingue. Au milieu une couche d'intégration faite de contrats plutôt que de câbles. En bas le cœur ERP, proche du standard et intact. À côté, délibérément à l'écart, une plateforme de données en lecture seule pour l'analyse et l'IA.

Les cinq règles qui tiennent cette architecture ensemble :

1. Un système de référence par objet de données. Pas par système, par objet. C'est inscrit dans la matrice de gouvernance des données, sinon cela ne vaut pas.
2. Aucun accès en écriture dans les tables de l'ERP. Uniquement via des interfaces prises en charge. Qui écrit directement dans la base vient de rendre sans valeur le contrat de maintenance de son éditeur d'ERP.
3. La logique métier appartient à l'extension. Pas aux modifications du cœur. C'est la même idée que votre éditeur d'ERP nomme Clean Core.
4. Chaque interface a un contrat. Ce qui arrive, dans quelle version, ce qui se passe en cas d'erreur, comment cela redémarre après un incident. Une interface sans reprise est une panne avec report de délai.
5. L'interchangeabilité fait partie de la conception. Une extension qui ne parle qu'à travers des contrats survit au changement de l'ERP en dessous.

La règle cinq est celle qui met fin au plus gros de la discussion au niveau DSI. Si une migration est de toute façon prévue, ce n'est pas un argument contre une application propre. C'est l'argument pour la sortir maintenant du cœur et la placer derrière un contrat. Ce qui se trouve à côté de l'ERP et ne parle qu'à travers des interfaces suit la migration. Ce qui se trouve dans le cœur devient une partie du risque de migration.

Deux choses traversent les trois bandes et sont régulièrement oubliées : une seule identité au lieu d'une gestion d'utilisateurs par application, avec des habilitations dérivées de l'annuaire existant et de l'ERP. Et une politique d'exploitation avec journalisation, supervision, reprise et responsabilité nommée. Depuis la loi de transposition de NIS2, cette dernière n'est plus seulement une bonne pratique. Les manquements aux nouvelles obligations exposent à des amendes allant jusqu'à 10 millions d'euros ou deux pour cent du chiffre d'affaires annuel, et les délais de notification sont de 24 heures pour l'alerte précoce et de 72 heures pour la déclaration.

Pourquoi c'est un sujet de différenciation et non un sujet informatique

Personne ne se distingue par le grand livre comptable. Ce n'est pas une provocation, c'est toute la raison d'être du logiciel standard et de sa qualité.

Vous vous distinguez par ce que votre client remarque : que vous chiffrez une fabrication spéciale en quatre jours et non en deux semaines. Que votre preuve de contrôle arrive complète avec la livraison. Que vous planifiez une commande intelligemment alors que quatre sociétés en dépendent. Ce sont des processus, pas des fonctions, et pour les processus il n'existe pas de standard, sinon ils ne seraient pas un avantage.

S'y ajoute un point qui est passé des ressources humaines à la stratégie informatique. Selon le rapport DIHK sur la main-d'œuvre qualifiée 2025/26, 36 pour cent des entreprises ne parviennent pas à pourvoir leurs postes ouverts, et cela frappe le plus durement précisément les tailles dont il est question ici : 44 pour cent des entreprises de 20 à 199 salariés et 47 pour cent de celles de 200 à 999.

Quand des effectifs supplémentaires ne sont plus une option disponible, le seul levier restant est que le travail corresponde mieux à chaque personne. C'est précisément le cœur économique d'une extension : non pas plus de fonctions, mais moins de frictions là où naît votre volume.

Et la limite reste la même que celle que nous traçons toujours : du sur mesure exactement là où votre processus vous distingue de la concurrence. Tout le reste, on l'achète. Qui construit sa propre paie brûle de l'argent, et nous le déconseillerions.

En quelles phases cela se construit

L'échec le plus fréquent dans ces projets n'est pas technique. C'est que la question la plus difficile est posée trop tard. D'où ce modèle en phases, dans lequel la question des interfaces avance vers l'avant.

Phase 0 : relevé des processus et des systèmes

• Objectif : comprendre ce qui se passe réellement, non ce qui figure dans le manuel.
• Résultat : le processus tel quel, un inventaire des systèmes et tableaux impliqués, et la première version de la matrice de gouvernance des données. Délibérément aucun cahier des charges.
• Qui doit être présent : les personnes qui font tourner le processus au quotidien, pas seulement leur encadrement.
• Critère d'arrêt : s'il apparaît ici que le processus peut être standardisé, arrêtez et prenez le module ERP.

Phase 1 : faisabilité de l'intégration

• Objectif : prouver que votre ERP peut réellement fournir et accepter les données nécessaires, à une vitesse suffisante et sans surprise de licence.
• Résultat : une petite liaison fonctionnelle contre le système réel, plus une indication sur les volumes et les temps de réponse.
• Qui doit être présent : votre partenaire ERP, et ici, pas plus tard.
• Critère d'arrêt : si les données nécessaires ne sont accessibles que par accès direct aux tables, c'est la conception qui est fausse, pas l'ERP.

Cette phase coûte quelques jours et sauve des projets. L'erreur classique consiste à construire six mois de logique métier puis à constater que l'interface ne fournit pas ce qui était supposé.

Phase 2 : un processus complet en production

• Objectif : une seule opération, mais du début à la fin, avec de vraies données et un petit groupe d'utilisateurs. Pas un prototype, pas trois demi-cas.
• Résultat : le premier processus qui tourne réellement dans le nouvel outil.
• Qui doit être présent : les futurs utilisateurs, en tant qu'utilisateurs en exploitation réelle, non en tant que groupe de test.
• Critère d'arrêt : si les utilisateurs tiennent encore leur liste après deux semaines, le périmètre est mal taillé, et davantage de fonctions n'y changeront rien.

Comment tailler cette première tranche verticale sur le cas d'usage central, nous l'avons consigné ici : Le cycle des exigences : pourquoi une spécification unique ne fonctionne pas.

Phase 3 : déployer et éteindre

• Objectif : retirer l'ancienne solution. C'est le contenu véritable de cette phase, et la partie la plus souvent omise.
• Résultat : le fichier Excel est archivé et hors circulation, l'outil remplacé est résilié.
• Qui doit être présent : celui qui possède et maintient l'ancienne solution aujourd'hui, sinon elle survit.
• Critère d'arrêt : si rien ne disparaît ici, le projet a rendu le paysage plus compliqué.
• À retenir : Une île qu'on n'éteint pas n'est pas un remplacement, c'est une île supplémentaire.

Phase 4 : exploitation et évolution

• Objectif : que l'extension devienne un système normal de votre maison.
• Résultat : supervision des interfaces avec alerte, une reprise éprouvée, une responsabilité métier et technique nommée.
• Qui doit être présent : les responsables désignés, désormais durablement et non par projet.
• Règle permanente : un test de non-régression exécuté contre les contrats d'interface avant chaque mise à jour de l'ERP.

Cette dernière règle décide si la solution sera encore aimée dans trois ans, ou seulement tolérée.

La conformité traverse l'ensemble, et dès le départ : reprendre les habilitations de l'ERP au lieu de les réinventer, journaliser qui a modifié quoi, et inscrire l'extension dans la politique de sécurité de la maison.

L'IA comme outil dans le projet, non comme promesse produit

Il ne s'agit expressément pas ici de fonctions d'IA dans le logiciel fini, mais de l'IA comme outil pendant l'intégration. C'est la partie dont on parle rarement dans les présentations au comité de direction et celle qui modifie le plus nettement la durée d'un projet.

Là où elle nous aide réellement :

Relevé des processus. Entretiens et échanges à l'atelier sous forme de transcription, et à partir de là une première description structurée du processus avec les questions ouvertes. Cela ne remplace aucune conversation, mais cela remplace la prise de notes et rend visible là où deux participants décrivent différemment la même étape.

Archéologie Excel. Le processus se trouve dans un tableur qui a grandi pendant onze ans. Formules, macros, cas particuliers dans des colonnes masquées. Un modèle peut extraire ces règles et les transformer en une liste lisible que l'on peut parcourir avec le métier. C'est le travail que personne ne voulait faire auparavant, et c'est le véritable trésor d'exigences.

Correspondance des interfaces. Générer des propositions de correspondance à partir des catalogues de champs et des descriptions d'interfaces de l'ERP, au lieu de les saisir à la main.

Cas de test et rapprochement. Générer des données de test pour les interfaces, et lors du basculement comparer les résultats de l'ancien et du nouveau pour trouver les écarts, au lieu d'espérer qu'il n'y en a pas.

Documentation et transfert. La partie qui, sans outillage, se fait toujours en dernier et trop brièvement.

À cela s'ajoutent trois garde-fous que nous ne négocions pas. L'IA propose, les humains décident. Aucune règle extraite ne passe en production sans revue métier, car une règle fausse formulée de façon plausible coûte plus cher qu'une règle manquante. Et : l'économie est réelle, mais elle n'est pas gratuite. Dans le rapport d'étude Bitkom 2026, 33 pour cent des entreprises déclarent que l'IA s'est révélée plus chère que prévu, et comme principaux obstacles elles citent le manque de compétences en IA dans l'équipe (53 pour cent), l'incertitude en matière de protection des données (41 pour cent) et des coûts flous (37 pour cent). Qui emploie l'IA dans un projet doit savoir s'en servir, pas seulement en acheter la licence.

Comment l'IA s'intègre en sécurité dans le paysage

Jusqu'ici, l'IA était un outil. Elle a aidé dans le projet, puis elle a quitté la pièce. À partir de maintenant, nous parlons d'autre chose, et ce changement est plus important qu'il n'y paraît.

Une fonction d'IA dans votre extension finie n'est pas une aide temporaire, c'est une composante système. Elle tourne en exploitation, elle traite durablement de vraies données, et elle a besoin d'une responsabilité nommée, d'une journalisation et d'une reprise éprouvée comme tout autre système issu de la phase 4. De ce fait, elle figure dans votre politique de sécurité.

Cette différence déplace la question. Avec l'outil, vous demandez : puis-je faire passer ces données une fois par ce modèle ? Avec la composante système, vous demandez : ce modèle peut-il traiter ces données durablement et sans surveillance, et qui répond du résultat ? La classification qui suit vous est nécessaire dans les deux cas, car l'outil dans le projet voit aussi de vraies données. Pour la composante système, elle n'est simplement pas négociable.

Où appartient cette composante, l'architecture ci-dessus l'a déjà décidé. Parce que le cœur ERP reste proche du standard, l'extension est l'endroit naturel pour les fonctions d'IA. Là, vous pouvez expérimenter, là, vous pouvez revenir en arrière, et là, un essai manqué ne met pas en danger votre comptabilité. Gartner s'attend à ce que, d'ici fin 2026, environ 40 pour cent des applications d'entreprise embarquent des agents d'IA spécialisés, contre moins de 5 pour cent en 2025. La question est donc moins de savoir si l'IA entrera dans votre paysage que par quel endroit.

Reste la question de savoir où tourne le modèle lui-même. On y répond le plus souvent de façon trop technique. L'ordre est autre : d'abord la classification du cas d'usage, ensuite le choix du modèle d'exploitation.

Car la classe de risque du règlement sur l'IA dépend de la finalité d'usage, non du centre de données. Un modèle dans votre propre atelier ne rend pas anodin un cas d'usage à haut risque. Depuis le 2 août 2026, le règlement est applicable de manière générale, avec des obligations de transparence et une supervision nationale, et des amendes pouvant atteindre 15 millions d'euros ou trois pour cent du chiffre d'affaires annuel mondial. Les obligations relatives aux systèmes à haut risque ont toutefois été reportées, par le biais du Digital Omnibus. C'est ainsi que l'UE nomme une loi collective qui modifie plusieurs règlements existants d'un seul coup, au lieu de reprendre chacun séparément. Il en existe une édition dédiée au règlement sur l'IA, en vigueur depuis le 27 juillet 2026 : elle reporte les obligations à haut risque au 2 décembre 2027 pour les systèmes autonomes relevant de l'annexe III, et au 2 août 2028 pour les systèmes intégrés dans des produits réglementés. La raison est prosaïque : les normes techniques harmonisées et les organismes d'évaluation n'étaient pas prêts à temps. Les exigences ne se sont donc pas assouplies, elles arrivent seulement plus tard. C'est du temps pour se préparer, et non une raison d'ajourner le sujet. Et un point important pour vous en tant qu'utilisateur : même si le fournisseur livre les justificatifs techniques, vous restez responsable de la manière dont le système est employé et surveillé dans vos processus.

Il en découle trois modèles d'exploitation, et les trois sont légitimes, pour des cas différents :

Sur site ou au bord de la production. Le modèle tourne sur votre propre matériel, aucune donnée ne quitte la maison. Adapté si vous traitez des données de conception, de production ou de chiffrage dont la fuite toucherait votre activité, si vous traitez des volumes élevés et réguliers, ou si un cas d'usage relève de la classe à haut risque et que vous voulez garder entièrement en main la journalisation et la traçabilité. Le prix, c'est le choix de modèle et la charge d'exploitation. Savoir si cela est rentable est une question de volumes et non de posture, et nous l'avons chiffrée ici : Une infrastructure IA locale en vaut-elle vraiment la peine pour une entreprise ?

Hébergement souverain dans l'UE. Exploitation dans une région européenne avec contrat de sous-traitance, sans utilisation de vos données pour l'entraînement, avec des engagements solides sur la conservation des données. Adapté à la majeure partie des cas portant sur des données personnelles et critiques pour l'activité, y compris à haut risque, si les obligations de documentation et de journalisation sont couvertes contractuellement et techniquement. L'offre de fournisseurs en Allemagne est désormais concrète, et ce n'est pas un hasard si la souveraineté numérique figure parmi les principales priorités d'investissement pour 2026 et 2027 dans l'enquête Lünendonk.

N'importe quel cloud. Pour des données non critiques et des tâches sans données personnelles ni secret d'affaires. Traductions de textes publics, aide à la formulation, recherche dans des sources ouvertes. Exiger ici un hébergement souverain coûte de l'argent sans contrepartie.

Deux décisions d'architecture vous gardent ce choix ouvert au lieu de le couler dans le béton une fois pour toutes :

Le modèle se trouve derrière votre propre point d'accès. Vos applications parlent à un endroit de votre paysage, non directement à un fournisseur. Le modèle d'exploitation devient alors sélectionnable par cas d'usage et modifiable plus tard, et vous journalisez en un seul endroit ce qui a été demandé et ce qui a été répondu. Vous en avez besoin autant pour les obligations de transparence que pour la traçabilité vis-à-vis de vos propres équipes. Sur le choix de tels points d'accès et sur la résidence des données, nous avons écrit ici : OpenRouter expliqué, et ce que cela signifie pour les équipes européennes.

L'IA ne parle jamais directement à l'ERP. Elle accède aux mêmes interfaces que l'extension elle-même, avec les mêmes habilitations. Vos rôles ERP restent ainsi effectifs, et personne ne peut voir via un assistant des données qu'il ne serait pas autorisé à voir dans le système métier. C'est la règle la plus souvent sautée dans les projets pilotes, et la seule qui empêche votre politique d'habilitations d'être contournée au passage.

Que cette prudence ne soit pas un frein mais une condition, l'écart d'adoption le montre : selon l'enquête DIHK 2026, 41 pour cent des entreprises utilisent activement l'IA, mais seulement 20 pour cent dans le Mittelstand, et les obstacles cités autour des données et de l'IA sont l'incertitude juridique (59 pour cent) et les difficultés techniques (50 pour cent). Qui clarifie au préalable la classification et le modèle d'exploitation fait partie des 20 pour cent, au lieu d'attendre que les choses s'éclaircissent. Comment bâtir la confiance pas à pas plutôt que tout risquer d'un coup, c'est ici : IA explicable pour les PME.

Cinq questions pour votre prochaine réunion informatique

Si vous ne devez retenir qu'une chose de cet article, retenez ces questions :

1. Lequel de nos processus nous distingue réellement de la concurrence ? Si la réponse compte plus de trois processus, elle n'est pas encore terminée.
2. Quelle modification de notre ERP paierons-nous une seconde fois à la prochaine montée de version ? Et laquelle pourrait se trouver à côté à la place ?
3. Quel système fait référence pour nos dix objets de données les plus importants ? S'il n'existe aucun document là-dessus, c'est la première tâche et elle coûte un après-midi.
4. Lesquelles de nos solutions isolées pourrions-nous éteindre ? Et pourquoi cela ne s'est-il pas produit lors du dernier projet ?
5. Quel cas d'usage d'IA pourrions-nous mettre en production dès aujourd'hui avec notre modèle d'exploitation actuel ? Si la réponse est « aucun », le problème n'est pas l'IA mais la classification manquante.

La décision dont il est question ici n'est pas ERP ou logiciel sur mesure. Cette opposition n'a jamais aidé personne, car les deux camps ont raison, simplement à des endroits différents.

La décision est de savoir si votre ERP peut rester allégé, pour que votre différence puisse grandir ailleurs.