2.1 Cahier des charges GMAO : analyse fonctionnelle du besoin

Un cahier des charges fonctionnel dit ce que l'utilisateur doit pouvoir obtenir, pas comment l'obtenir. La nuance paraît académique ; elle change pourtant la nature de la consultation. Écrire « le logiciel doit comporter un écran de planning en diagramme de Gantt » décrit un moyen. Écrire « le planificateur doit pouvoir répartir les ordres de travail de la semaine entre les équipes en visualisant leur charge » décrit un besoin, que plusieurs solutions peuvent satisfaire.

Cette formulation laisse aux candidats la liberté de proposer leur façon de faire, et elle donne à l'acheteur un critère de jugement : la solution permet-elle, oui ou non, de répartir la charge de façon lisible ? Le moyen proposé se juge ensuite en démonstration, sur des cas réels du site.

Le cahier des charges fonctionnel ne remplace pas les spécifications détaillées. Celles-ci viennent après le choix, pendant le paramétrage, quand l'équipe projet décrit avec l'éditeur retenu les statuts d'OT, les profils ou les codes de défaillance. Mélanger les deux documents produit un cahier des charges de cent pages que personne ne lit en entier, ni chez l'acheteur ni chez les candidats.

L'expression fonctionnelle du besoin est normalisée. La norme de référence est la NF EN 16271, publiée par l'AFNOR en février 2013 (indice de classement X50-151). Son titre en résume l'objet : « Management par la valeur — Expression fonctionnelle du besoin et cahier des charges fonctionnel — Exigences pour l'expression et la validation du besoin à satisfaire dans le processus d'acquisition ou d'obtention d'un produit ».

Elle remplace la NF X50-151 de septembre 2007, annulée. Beaucoup de supports de formation et de modèles de cahier des charges continuent de citer la X50-151 : la référence est périmée, même si la démarche qu'elle décrivait reste proche.

Les idées du management par la valeur, en clair

Sans reproduire la norme, qui est payante, on peut résumer les notions qu'elle mobilise et qui structurent tout cahier des charges fonctionnel :

• une fonction de service est une action attendue du produit pour répondre au besoin d'un utilisateur, exprimée par un verbe et un complément (« permettre au demandeur de signaler une anomalie ») ;
• une contrainte est une limite imposée à la solution, qui ne se négocie pas de la même façon qu'une fonction (compatibilité avec le système d'information, règles de sécurité, langue, budget) ;
• chaque fonction est assortie de critères d'appréciation, c'est-à-dire de ce qu'on regarde pour juger qu'elle est remplie ;
• chaque critère reçoit un niveau attendu, chiffré quand c'est possible ;
• chaque niveau est accompagné d'une indication de flexibilité : la marge que l'acheteur est prêt à accepter, qui dit aux candidats où ils peuvent proposer une variante.

La logique d'ensemble est celle de la valeur : rapprocher la satisfaction du besoin et le coût pour l'obtenir. Un cahier des charges qui n'exprime ni niveaux ni marges oblige à comparer des offres qui ne répondent pas à la même question.

Partir de l'existant

L'état des lieux décrit ce qui se fait aujourd'hui, même si c'est dans un tableur, un classeur de bons papier ou une ancienne GMAO. Il recense le périmètre (sites, ateliers, nombre approximatif d'équipements), les processus réellement pratiqués, les documents produits, les outils en place et leurs interfaces. Il liste aussi les irritants : ce qui fait perdre du temps, les informations introuvables, les doubles saisies.

Cet état des lieux se fait sur le terrain, avec les techniciens et le magasin, pas seulement avec le responsable maintenance. La façon dont un technicien retrouve aujourd'hui l'historique d'une pompe dit plus sur le besoin qu'une liste de modules.

Identifier les parties prenantes

Une GMAO est utilisée par bien plus de monde que le service maintenance. Chaque population a ses fonctions de service propres :

Formuler les fonctions et les contraintes

Les fonctions de service se rédigent une par ligne, avec un verbe d'action et un bénéficiaire : « permettre au magasinier de connaître le stock disponible d'une pièce et son emplacement ». Les contraintes se regroupent à part : exigences de sécurité de l'informatique, langues, compatibilité avec l'ERP, contexte réglementaire, délais du projet.

Les droits d'accès font partie de ce travail : qui peut créer un OT, qui peut le clôturer, qui peut modifier une gamme. Ils sont traités en détail dans le chapitre rôles, droits et gestionnaire GMAO.

Il n'existe pas de plan imposé. Le sommaire ci-dessous couvre les rubriques qu'un candidat doit trouver pour chiffrer sérieusement, et celles qu'on oublie le plus souvent jusqu'au contrat.

Pourquoi la volumétrie compte

Sans volumétrie, un candidat ne peut chiffrer ni l'abonnement, ni la reprise, ni l'effort de paramétrage. Des ordres de grandeur suffisent. Exemple fictif de rédaction : « environ 900 équipements codifiés sur deux sites, 2 500 articles en magasin, 4 000 OT par an dont 60 % de préventif, 12 techniciens, 3 planificateurs, 80 demandeurs occasionnels ». Le candidat en déduit le modèle de licence adapté et la charge de reprise.

Les interfaces méritent le même effort de précision : quelles données circulent, dans quel sens, à quelle fréquence. Le détail technique des connecteurs et des API est traité dans le chapitre intégration GMAO-ERP et API de la formation Data maintenance ; l'architecture fonctionnelle d'une GMAO, dans le chapitre architecture GMAO.

Une fonction sans critère ne peut pas être vérifiée. Pour chaque fonction importante, le cahier des charges indique ce qu'on mesure, le niveau attendu et la marge acceptable. L'exemple ci-dessous, rédigé pour l'illustration, montre la mécanique :

Exigences obligatoires et exigences souhaitées

Toutes les fonctions ne pèsent pas le même poids. Classer chaque exigence en obligatoire ou souhaitée simplifie la suite de la consultation :

Un bon test : si plus de la moitié des exigences sont marquées obligatoires, le classement ne trie plus rien. Les exigences obligatoires doivent rester peu nombreuses et réellement éliminatoires. La façon de noter les exigences souhaitées et de comparer les offres est détaillée au chapitre comparer les offres de GMAO.

Deux autres travers reviennent souvent. Le premier consiste à rédiger sans volumétrie ni calendrier, ce qui produit des offres impossibles à comparer. Le second consiste à oublier les critères de jugement : si les candidats ne savent pas comment ils seront évalués, ils optimisent leur réponse sur le prix affiché.

Le cahier des charges est aussi le premier acte de la conduite du changement : les personnes associées à sa rédaction deviennent souvent les référents du déploiement. La démarche est développée dans la formation Conduite du changement.

Un cahier des charges GMAO se construit en quelques ateliers courts plutôt qu'en une rédaction solitaire. Le pilote du projet, souvent le responsable maintenance ou un ingénieur méthodes, tient la plume ; les autres apportent leur besoin et relisent.

Rédiger une exigence : un modèle simple

Chaque exigence gagne à suivre la même structure, ce qui facilite la réponse des candidats et la comparaison. Exemple fictif :

Cette numérotation sert ensuite à tout le projet : les candidats répondent ligne par ligne, la grille de sélection reprend les mêmes références, et la recette du logiciel vérifie les exigences une à une. Un tableur partagé suffit pour tenir ce référentiel.

Les notions de préventif systématique et conditionnel, indispensables pour rédiger ces exigences, sont rappelées dans les chapitres maintenance préventive systématique et maintenance préventive conditionnelle de la formation Fondamentaux de la maintenance.