Cahier des charges ERP ou MES : comment obtenir des offres réellement comparables ?

En synthèse

Un cahier des charges ERP ou MES doit permettre aux candidats de chiffrer un même besoin, avec des hypothèses visibles et des engagements vérifiables. Sa qualité se mesure à la clarté des réponses obtenues et à sa capacité à servir de référence pendant le projet.

Pour y parvenir, il faut relier les objectifs opérationnels aux scénarios métier, préciser les contraintes techniques et imposer un cadre de réponse commun. L’intelligence artificielle, la cybersécurité et la connexion des équipements doivent y trouver leur place au même titre que les fonctionnalités et les prestations de déploiement.

Trois offres reçues, trois périmètres différents

Imaginons une entreprise qui consulte plusieurs partenaires pour son futur MES. Le premier inclut la connexion des machines. Le deuxième prévoit une enveloppe d’interfaces, sans détailler les équipements concernés. Le troisième suppose que les données seront déjà disponibles sur une plateforme fournie par le client.

Les trois candidats annoncent couvrir le suivi de production. Pourtant, leurs propositions ne financent pas le même résultat. Le même décalage peut concerner la reprise des données, les terminaux d’atelier, la formation, les licences ou le support.

Cette situation illustrative montre la limite d’une consultation fondée sur des intitulés génériques. Avant de négocier les prix, il faut rendre visibles les écarts de périmètre. Le cahier des charges prépare cette comparaison.

1. Définir les résultats attendus et les limites du projet

Le point de départ est le problème opérationnel : ressaisies, manque de visibilité, traçabilité incomplète, stocks peu fiables ou lenteur de traitement. Il faut en décrire les conséquences, les situations concernées et, lorsque c’est possible, la situation de référence.

« Améliorer la traçabilité » exprime une intention. « Retrouver, pour un lot fini, les lots matières consommés, les opérations réalisées et les contrôles associés » décrit déjà un résultat vérifiable. Le délai de restitution, la profondeur d’historique et les droits d’accès restent à préciser.

Le périmètre doit identifier les sites, activités, populations, systèmes et équipements concernés, ainsi que les exclusions. Séparer le premier déploiement des extensions envisagées permet de demander un prix ferme sur un périmètre défini et des options clairement isolées pour la suite.

2. Décrire les scénarios métier et les exceptions

Une liste de fonctions gagne à être accompagnée de scénarios concrets. Pour chaque processus critique, préciser l’acteur, l’événement déclencheur, les données disponibles, les contrôles, les échanges entre systèmes et le résultat attendu.

Prenons la déclaration d’une consommation matière : l’opérateur identifie l’ordre, scanne le lot, saisit ou récupère la quantité, puis valide. Le système contrôle l’éligibilité du lot et transmet le mouvement à l’ERP. Il faut aussi définir le traitement d’un lot bloqué, d’une quantité incorrecte et d’une déclaration à annuler.

Que se passe-t-il si la connexion est interrompue après validation ? L’opérateur voit-il que le mouvement reste en attente ? Qui peut le reprendre ? Comment éviter une seconde consommation lors du renvoi ? Ces questions orientent simultanément la conception, le chiffrage et la recette.

3. Donner aux exigences techniques la même précision qu’aux besoins métier

Les choix technologiques influencent le coût, la disponibilité et la capacité à faire évoluer la solution. Le dossier doit distinguer les contraintes imposées par l’entreprise des options pour lesquelles elle attend une proposition argumentée. L’inventaire existant, les schémas d’architecture et les inconnues à lever doivent être partagés avec les candidats.

Architecture, données et continuité d’activité

Clarifier les responsabilités respectives de l’ERP, du MES, de la supervision et des automates : qui crée l’ordre, autorise une opération, détient le statut qualité et conserve l’historique ? Préciser les objets échangés, leur sens de circulation et le système faisant référence.

Une architecture cloud, locale ou hybride doit être évaluée selon les contraintes du site : latence acceptable, disponibilité réseau, localisation des données et dépendance aux services externes. Définir les activités qui peuvent continuer en cas de coupure, celles qui doivent s’arrêter et les modalités de resynchronisation.

Demander les objectifs de reprise après incident : délai de remise en service (RTO) et perte de données maximale acceptable (RPO). Ajouter les durées de conservation, la supervision, les alertes, les modalités de sauvegarde et les tests de restauration. Les valeurs doivent découler des risques métier.

Équipements physiques et contraintes de l’atelier

Un écran utilisable au bureau peut devenir inadapté avec des gants, un éclairage difficile ou un poste partagé. Décrire les conditions réelles : température, poussière, humidité, nettoyage, contraintes de zone, lisibilité, mobilité et alimentation électrique. Les niveaux de protection et certifications nécessaires sont à définir selon l’environnement.

Inventorier les PC industriels, terminaux mobiles, lecteurs de codes, imprimantes, balances, capteurs, automates et passerelles. Préciser les modèles, versions, systèmes d’exploitation, interfaces disponibles et durées de support connues. Vérifier la couverture réseau là où les opérations ont effectivement lieu.

Le candidat doit distinguer les matériels réutilisables, ceux à remplacer et les essais préalables nécessaires. L’achat, l’installation, les pilotes, les licences de connexion, les pièces de rechange et la maintenance doivent avoir un responsable et une ligne de coût identifiables.

Protocoles machine : demander une compatibilité démontrée

La mention « compatible OPC UA » ne décrit pas à elle seule une interface. Il faut préciser les équipements et versions, les données exposées, les droits de lecture ou d’écriture, les fréquences, les horodatages et le comportement en cas d’erreur. OPC UA propose notamment des mécanismes de modélisation des informations et de sécurité ; leur utilisation effective doit être vérifiée dans la configuration proposée. [1]

Ces mécanismes peuvent coexister et ne sont pas interchangeables. MQTT transporte des messages selon un modèle de publication et d’abonnement, sans imposer le contenu métier de leur charge utile. Le schéma des données doit donc être défini séparément. Les garanties de livraison du protocole ne dispensent pas de vérifier le traitement métier de bout en bout. [2]

Pour une connexion incertaine, prévoir un essai sur un équipement représentatif. Dans notre scénario, le renvoi d’une déclaration après coupure ne doit pas créer deux mouvements de stock. L’identifiant de transaction, la détection des doublons et la réconciliation doivent être explicités.

Cybersécurité : des responsabilités et des preuves

La sécurité doit intégrer les contraintes propres aux systèmes industriels : disponibilité, fiabilité et sécurité physique des opérations. Le guide NIST SP 800-82 fournit un cadre de référence pour cette approche OT, c’est-à-dire les technologies qui surveillent ou commandent les équipements. [3]

Demander aux candidats de documenter la segmentation IT/OT, les flux réseau nécessaires, les droits minimaux, la traçabilité des accès et les modalités de télémaintenance. Les accès distants doivent préciser l’authentification, l’autorisation, la durée d’ouverture et les possibilités de révocation.

Répartir aussi la gestion des correctifs, vulnérabilités, certificats, sauvegardes et incidents entre entreprise, intégrateur, éditeur et mainteneur. Une mise à jour doit pouvoir être préparée, testée et accompagnée d’un retour arrière adapté au contexte industriel.

Les preuves attendues peuvent inclure une revue d’architecture, une matrice de flux validée, un test de restauration et la démonstration de fermeture d’un accès prestataire. Ces exigences sont à valider avec les responsables cybersécurité et automatisme.

IA : exiger un usage précis et une performance vérifiable

Une fonction d’IA doit être décrite par le service rendu : retrouver une instruction, proposer une synthèse, détecter une anomalie ou assister une décision. Le dossier doit distinguer assistance documentaire, modèle prédictif et action sur un processus ; leurs critères d’évaluation diffèrent.

Pour un assistant documentaire, demander les sources autorisées, le respect des habilitations, la référence aux documents utilisés et le comportement lorsque l’information manque. Pour une détection d’anomalies, préciser les données nécessaires, les faux positifs et faux négatifs acceptables, ainsi que le suivi des performances dans le temps.

La réponse fournisseur doit préciser où les données sont traitées, combien de temps elles sont conservées, si elles peuvent être réutilisées pour entraîner des modèles et quelles dépendances externes sont introduites. Demander également les coûts d’usage, la gestion des changements de modèle, les possibilités de désactivation et le fonctionnement de secours.

La recette doit utiliser un jeu de cas représentatif, distinct des exemples de démonstration du fournisseur. Définir les validations humaines, les actions interdites et la journalisation nécessaire avant toute écriture dans l’ERP ou action sur la production. Les travaux du NIST sur la gestion des risques de l’IA et de l’IA générative fournissent des repères pour structurer cette évaluation. [4]

4. Prioriser les exigences et définir les preuves attendues

Classer tous les besoins en « obligatoire » empêche d’arbitrer. Séparer les exigences indispensables au démarrage, les besoins souhaitables et les évolutions ultérieures. Identifier les critères réellement éliminatoires, puis documenter les compromis acceptables.

Chaque exigence critique doit disposer d’un identifiant, d’une justification métier, d’un responsable et d’un critère d’acceptation. Les seuils chiffrés doivent être validés avant consultation ; les valeurs ci-dessous sont uniquement illustratives.

Un statut « couvert » devient ainsi une affirmation à étayer. Si la fonction dépend d’un connecteur supplémentaire ou d’une modification d’automate, le candidat doit l’indiquer dans sa réponse.

5. Imposer un cadre de réponse commun

Fournir une trame facilite l’analyse et oblige chaque candidat à rendre ses hypothèses visibles. Pour chaque exigence, demander la solution proposée, les limites, les dépendances, les prestations incluses et les éléments de preuve.

Compléter cette matrice par un chiffrage commun : logiciels, interfaces, données, équipements, infrastructure, cybersécurité, déploiement, formation, assistance au démarrage et support. Les consommations cloud ou IA doivent reposer sur des hypothèses de volume partagées.

Exiger un planning faisant apparaître les contributions de l’entreprise : disponibilité des utilisateurs clés, correction des données, interventions automatisme, validation sécurité et fenêtres d’arrêt. Préciser les livrables, les exclusions, les modalités de gestion des changements et les éléments nécessaires à la réversibilité.

6. Comparer sur un périmètre et des preuves équivalents

Commencer par relever les hypothèses divergentes et les postes manquants. Faire clarifier les écarts, puis comparer les offres sur une durée commune, par exemple cinq ans, avec les mêmes volumes, sites et utilisateurs. Ce choix est une hypothèse de comparaison à adapter.

Le coût total doit intégrer les dépenses internes et les coûts récurrents : exploitation, support, connecteurs, renouvellement du matériel, consommation des services et maintien des spécifiques. Les montants incertains doivent rester visibles, avec leurs hypothèses.

Traiter les critères éliminatoires avant la notation pondérée : un bon score global ne compense pas une exigence indispensable non satisfaite. Une fonction d’IA doit être évaluée pour sa contribution au besoin, avec ses risques et coûts, sans prime automatique à la nouveauté.

Organiser les démonstrations sur les mêmes scénarios et jeux de données. Pour la consommation matière, demander le cas nominal, un lot interdit et une reprise après incident. Consolider les clarifications importantes dans l’offre finale et les documents de référence retenus pour le projet.

Avant de lancer la consultation

• Les objectifs, le périmètre initial et les exclusions sont validés par les métiers.
• Les scénarios critiques couvrent les exceptions et le fonctionnement dégradé.
• Les systèmes, équipements, protocoles et inconnues techniques sont recensés.
• Les responsabilités sur les données, la sécurité et l’exploitation sont précisées.
• Les usages d’IA disposent de critères d’évaluation, de limites et de règles sur les données.
• Le cadre de réponse distingue couverture, hypothèses, coûts et contributions du client.
• Les critères d’acceptation et la méthode de comparaison sont définis.

Un cahier des charges qui reste utile après la sélection

Le dossier de consultation prépare aussi l’exécution. Les scénarios deviennent des références de conception et de recette ; les exigences facilitent l’analyse des écarts ; les responsabilités limitent les zones grises entre métiers, IT, automatisme et prestataires.

Le niveau de détail doit rester proportionné à la criticité du projet. L’enjeu est de rendre les décisions structurantes explicites, en laissant aux candidats l’espace nécessaire pour proposer des solutions pertinentes et argumentées.