La Maintenabilité, Réparabilité: définition, explication et exemple. Dit «Maintainability » et « Repairability » en Anglais, cette notion impacte directement votre capacité à assurer le Support de vos Produits. Méthodes Simples pour concevoir un Produit réparable.
La Maintenabilité est la capacité d’un Produit à être maintenu. Il s’agit de l’ensemble de ses caractéristiques qui permettront à une personne définie de pouvoir réparer le Produit en cas de casse, ou de manière préventive.
On retrouve parfois l’expression « réparabilité ». La Maintenabilité est le "M" de l'acronyme FMDS (ou RAMS, en Anglais).
L’objectif des activités de Maintenabilité lors de la conception de son Produit est d’assurer par le design de ce dernier (son architecture, ses fonctions, ses composants, ses interfaces) qu’il sera maintenable efficacement.
Maintenable efficacement signifie :
Pour qu’un Système soit au top de la Maintenabilité, il est nécessaire qu’elle ait été pensée dès la conception du Système. On parle de « Design for Maintainability ».
Exemple: il est très facile de changer les piles de votre télécommande de TV, car tout a été prévu pour ! Ouverture facile sans outils, piles standardisées et disponibles dans tous les supermarchés, pas de "réinitialisation" à faire etc.
La Maintenance est l’ensemble des actions à effectuer de manière proactive ou réactive sur un Produit afin de garantir l’état opérationnel attendu et/ou obtenir une extension de sa durée de vie.
Si les actions sont proactives, on parle de Maintenance Préventive (dite aussi Prédictive, ou Systématique, ou Prévisionnelle, ou Planifiée, ou Conditionnelle). Il s’agit d’actions de réparations/inspections/nettoyages prévues sur votre Système avant défaillances afin de le maintenir en bon état de marche.
Si les actions sont réactives, on parle de Maintenance Corrective (ou Palliative, ou Curative). Le Système fonctionnait bien jusqu’à ce que quelque chose casse, et on déroule alors un certain nombre d’actions pour restaurer le bon état de marche.
Il existe également, si le Système s’y prête, de la Maintenance Evolutive (ou Améliorative, ou d’amélioration tout court). Il ne s’agit pas de maintenir un état opérationnel attendu du Système, mais de l’améliorer. Dans le jargon militaire, on parle de Modernisation ou rétrofit. Cela peut être fait en proactif ou en réactif.
Exemples :
La maintenance peut se faire :
On peut définir plusieurs niveaux de maintenance :
Exemples :
La maintenance peut se faire en downtime du Système, ou même uptime si le système est prévu pour.
Exemple :
Ceci se pense dès la conception de son Produit.
Ces notions sont associées dans l’acronyme RAM (resp. RAMS) : Reliability, Availability, Maintainability (resp. idem + Safety).
En français on parle de FMD et FMDS (Fiabilité, Maintenabilité, Disponibilité, Sécurité/Sûreté)
Je reviendrai dans un futur article sur la Disponibilité d’un Produit. Pour l’heure, on peut déjà dire que la Disponibilité est la probabilité qu’un Produit soit prêt et fonctionnel au moment où je souhaite m’en servir. On intuite alors que si le Produit est difficilement maintenable, il passera peut-être plus de temps en atelier réparation que sur le terrain à fonctionner si en plus le taux de Fiabilité est faible.
Maintenabilité basse --> Disponibilité impactée négativement !
Exemple :
Et quel est le lien avec la Fiabilité ?
Les actions de maintenance préventives --> jouent en faveur de la Fiabilité
Exemple :
La Maintenabilité peut être exprimée sous plusieurs formes :
Il s’agit alors, dans sa conception de Produit, de se donner des contraintes et des objectifs pour satisfaire au choix un temps, un coût, une fréquence d’intervention, des outils, etc.
Exemple : Je souhaite que mon Système soit maintenable pour la maintenance de niveau 2 en moins de 4h par 1 personne formée, avec outils courants, sur site client.
→ ici c’est le temps, le nombre de personnes et leur formation préalable, les outils et le lieu qui priment.
Vous avez des contraintes et objectifs (cf. paragraphe ci-dessus) sur cette maintenance que vous avez réfléchi en interne de votre entreprise, et avec vos clients.
Dans votre analyse de Besoin, intégrez ces objectifs et ces contraintes sous formes d’Exigences de Besoin.
Ensuite, lors des déclinaisons successives pour passer d’un besoin à une Spécification, puis à une Conception, puis à un Développement : définissez clairement quelle est cette maintenance (quelles réparations ? de quels composants hardware, software, mécanique ? Par qui ? Avec quels outils ? En quelles conditions ? En combien de temps ? etc.).
Mettez en place l’architecture Produit en face afin de respecter ces exigences : architecture produit et/ou l’infrastructure autour de ce produit également.
Exemple : si on pense IoT
Dans le coût total d’un Système (et également dans ce qu’il peut rapporter en termes de Chiffre d’Affaires), les phases de Maintenance ne sont pas à négliger. Pour ce coût total, on parle de TOC (Total Cost of Ownership).
Des Méthodes pour assurer la Maintenabilité de son Produit (la définir, et la vérifier) se trouvent dans des normes. Les trouver et les lire sera des plus instructif !
Exemple : IEC 60706
Rédigez en parallèle de la conception de votre Système le processus à suivre pour :
Le fait de penser à ce processus en amont implique de penser aux parties utiles de notre Système qu’il faudrait avoir pour la maintenance, les outils, l’interface entre les 2 etc. Et y penser permet de mettre en place tout cela avant même que le Produit n'arrive sur le marché.
Vous vérifiez de manière certes amont mais tout à fait pragmatique si l'architecture que vous êtes en train de constituer pour votre Produit (et ses outils éventuels) pourra bien être mise en oeuvre comme attendue sur le terrain pour atteindre les Spécifications définies.
Exemple : éléments qui peuvent apparaître comme manquants lors de la rédaction d'un manuel, même préliminaire
De la même manière qu’il y a plusieurs niveaux de Maintenance, il peut y avoir plusieurs niveaux de Manuels de Maintenance pour les intervenants qui officient sur ces différents niveaux.
Pour s’assurer que tout est OK une fois que la personne en charge des réparations a effectué la maintenance du Produit (qu’elle eut été réactive ou proactive) : des tests sur ce Produit sont à faire avant de le déclarer à nouveau apte au fonctionnement.
Les tests de ce manuel vont jouer également sur le Design du Produit. Si vous souhaitez que le mainteneur puisse faire un « passage de valise » sur le Système après sa réparation, alors il faut qu’il y ait un connecteur accessible quelque part sur votre Système ainsi qu’un processus logiciel associé à la Maintenance en son sein !
A la suite de votre démarche d’Architecture Systèmes, comportant un certain nombre de tests de Fiabilité, vous vous rendez compte que certaines composantes de votre Produit sont soumises plus que les autres à la dégradation.
Exemple :
Il semble donc une bonne idée d'en prévoir sous forme de pièces détachées un stock de roulement, chez vous, votre client ou votre mainteneur, afin de dépanner au plus vite les Produits touchés (et ainsi impacter favorablement la Disponibilité du Produit).
Les activités à prévoir pour ces composants seront nombreuses :
Si votre entreprise est capable de mettre en place et coordonner ces activités, pas de problème.
Sinon, peut-être vaut-il mieux ne pas mettre ce composant problématique dans votre pPoduit et penser dès la Conception à modifier l’architecture Produit ? D’où l’utilité de penser à ces concepts pendant les phases amonts de votre Développement.
Par ce modeste article, j’espère avoir éclairé ce qu’est la Maintenance et la Maintenabilité/Réparabilité d’un Produit.
Je ne puis insister assez sur le fait de penser à la Réparabilité de son Produit dès les phases de Spécification et Conception de ce dernier. Cela permet d’anticiper cette phase cruciale (niveau coûts et… Chiffre d’Affaires !) qu’est le Support.
L’Architecture Systèmes est un moyen très performant de se poser ces questions qui fâchent dès le début, et ainsi ne pas négliger ce sujet ni se retrouver piégé ensuite avec un Système difficilement réparable mais dont on doit assurer la Maintenance.
Aurélien NARDINI
Un Système Sans Problème est une ressource de connaissances et de savoir-faire pratiques, avec exemples concrets.
Que vous soyez Chef de Programme, Chef de Projet, Architecte Système, Ingénieur, Manager dans l'Industrie, Etudiant ou Curieux de l'Ingénierie, vous êtes au bon endroit.
Au travers d'articles publiés régulièrement, découvrez ou révisez les Processus, Méthodes, Outils et Astuces utiles pour concevoir et piloter dans les domaines du Software, Firmware, de l’Électronique, et de la Mécanique.
Parce-qu'un produit fiable et industrialisable ne s'improvise pas !
