Partir des opérations observées
Le cahier des charges commence par une description courte de l’activité : nombre de sites, familles de produits, zones, équipes, horaires, systèmes et changements attendus. Pour chaque chiffre, indiquez la période et la provenance. Ne gonflez pas les volumes pour obtenir une marge de capacité théorique; séparez le mesuré, le prévu et le scénario de pointe.
Cartographiez chaque flux de bout en bout. Pour une réception, décrivez l’avis attendu, le contrôle, l’écart, l’identification et la mise à disposition. Pour une préparation, précisez le déclencheur, la règle de regroupement, les contrôles et la confirmation. Une phrase comme « gérer les commandes » est trop large pour être testée.
Les exceptions révèlent les exigences déterminantes : article inconnu, quantité différente, poste de travail bloqué, information absente, retour ou étiquette illisible. Décrivez ce qui arrive, qui peut décider, quelle trace est conservée et comment l’opération reprend. Ne demandez pas au logiciel de masquer un processus que les équipes n’ont pas encore arbitré.
Écrire des exigences vérifiables
Formulez chaque exigence avec un acteur, une action, un contexte et un résultat observable. Au lieu de « le système est intuitif », demandez à un rôle défini d’exécuter un scénario précis après une formation prévue, puis décrivez le temps ou la preuve que votre organisation juge utile. Évitez les promesses de performance sans mesure, environnement et conditions d’essai.
Classez les exigences en indispensables, importantes et souhaitables. Expliquez pourquoi les premières sont bloquantes. Pour chacune, notez le propriétaire métier, le système concerné, les données d’entrée, la sortie attendue, la méthode de vérification et les dépendances. Cette structure facilite les réponses des éditeurs et évite qu’une liste de fonctions génériques remplace les besoins.
Précisez les limites d’exploitation : périodes de fermeture, connexion disponible, appareils autorisés, rôle des prestataires, procédures en mode dégradé et contraintes d’accès. Séparez les politiques internes des fonctions demandées au fournisseur. Les obligations techniques doivent être examinées par les personnes responsables de la sécurité et de l’informatique.
Décrire un cycle de fabrication testable
Pour chaque opération, écrivez les prérequis, l’ordre de fabrication, le poste concerné, la quantité attendue, les événements collectés et la condition de fin. Précisez si la déclaration provient d’un opérateur, d’un automate ou d’une interface. Séparez une obligation de traçabilité interne d’une préférence d’écran. Les critères doivent être vérifiés sur un jeu fictif et une version définie, sans intégrer de paramètres de sécurité machine dans un cahier logiciel non revu par les spécialistes.
Décrire les données et interfaces
Inventoriez les données maîtres et transactionnelles : articles, unités, postes de travail, règles de lot, utilisateurs, commandes, réceptions, mouvements et inventaires. Indiquez le propriétaire, le système source, le format, la fréquence et les règles de qualité. Un exemple anonymisé aide à clarifier les champs sans transmettre de données sensibles dans un document largement partagé.
Pour chaque interface, nommez les deux systèmes, le sens des échanges, le déclencheur, le format, la fréquence, l’identifiant de rapprochement, la gestion d’erreur et le responsable de support. Demandez si la connexion est standard, configurée ou développée. « Connecté à l’ERP » n’indique pas si les événements sont transmis en temps réel, par lot, ou ressaisis manuellement.
Définissez les exigences d’export et de restitution avant la sélection. Faites préciser les formats, les métadonnées, les pièces jointes, les historiques et les restrictions de service. La portabilité ne se résume pas à télécharger un fichier produits. Demandez un exemple concret d’export et les responsabilités en cas de fin de contrat.
Préparer une réponse comparable
Fournissez à chaque candidat le même jeu de scénarios et un modèle de réponse qui demande : standard, paramétrage, développement ou non couvert. Exigez les hypothèses, limites, frais ponctuels, récurrents et dépendances. Laissez une place pour une question ou un désaccord; la clarté sur un point non couvert est plus utile qu’une réponse affirmative non définie.
Précisez le format de démonstration : données fictives, rôles, durée, scénarios, exceptions, appareils, preuves attendues et participants métier. Faites déclarer les éléments qui ne sont que maquettes ou environnements de démonstration. Une feuille de décision reliera chaque exigence à une réponse écrite et à une preuve observée.
Un cahier des charges n’est pas un contrat complet ni une prescription de sécurité. Faites examiner les sections pertinentes par les opérations, l’informatique, les achats et les responsables des données. La documentation France Num sur le choix des logiciels de gestion peut fournir un point de départ général, sans remplacer l’analyse de votre atelier de production.
Sources et limites
Les sources éclairent des questions de cadrage; elles ne valident pas votre architecture ni un fournisseur. Les standards et documentations cités restent la propriété de leurs éditeurs et ne remplacent pas l’analyse de votre site.