← Retour au blog

Cahier des charges GMAO maritime : le guide de rédaction

Tangi Capitaine

Un cahier des charges GMAO n'est pas un document administratif. C'est l'outil qui décide si les réponses des éditeurs seront comparables ou non. Quand le document est flou, chaque éditeur répond à sa propre question, les chiffrages varient du simple au triple sans qu'on sache pourquoi, et l'armateur choisit au feeling. Quand il est précis, les écarts de prix deviennent lisibles et les impasses techniques apparaissent avant la signature, pas six mois après la mise en service.

Ce guide s'adresse à ceux qui ont déjà arbitré le principe : la flotte passe sur une GMAO maritime, le tableur a atteint ses limites. Reste à écrire le document qu'on enverra aux éditeurs. Chaque section ci-dessous donne le pourquoi, le piège classique, et des formulations d'exigences que vous pouvez reprendre telles quelles, en remplaçant les valeurs entre crochets par les vôtres.

Cadrer le périmètre : la section qui fausse tout le reste

Le périmètre est la première section du document et la seule que tous les éditeurs lisent en entier, parce que c'est elle qui détermine le chiffrage. Un périmètre mal cadré ne produit pas une erreur de quelques pour cent sur le devis : il produit un devis qui ne veut rien dire.

Ce qu'il faut poser noir sur blanc : le nombre de navires et leur typologie, les pavillons concernés, la répartition des utilisateurs entre le bord et le terre, l'organisation technique (un superintendant pour toute la flotte, ou un responsable par navire), et la cible à trois ans. Une compagnie de six navires qui en visera quatorze dans trois ans ne doit pas se retrouver à renégocier sa licence au premier rachat.

Le piège classique

Compter les navires et oublier les utilisateurs. Un ferry avec quatre officiers mécaniciens, un second capitaine et un service technique à terre de trois personnes, ce n'est pas la même charge de licence qu'un fileyeur de 24 mètres avec un patron et un mécanicien. Deuxième piège : ne pas dire si les équipages doubles comptent pour un ou deux utilisateurs. C'est la ligne qui fait dériver le budget dès la première relève.

Exigences à reprendre

  • PER-01 — « La solution devra couvrir [N] navires à la mise en service, avec une capacité d'extension à [N+X] navires sur la durée du contrat sans refonte de l'architecture ni migration de données. Le soumissionnaire indiquera le mode de tarification appliqué à l'ajout d'un navire en cours de contrat. »
  • PER-02 — « Les navires concernés sont : [type, longueur, pavillon, zone d'exploitation, effectif embarqué] pour chacun. Le soumissionnaire précisera si sa solution impose une configuration distincte par pavillon. »
  • PER-03 — « L'organisation comprend [N] utilisateurs embarqués et [N] utilisateurs à terre. Le soumissionnaire précisera si la tarification est fondée sur les comptes nominatifs, les connexions simultanées ou le navire, et le traitement appliqué aux équipages en rotation. »

Le fonctionnement hors connexion : ne jamais écrire « doit fonctionner hors ligne »

« Le logiciel doit fonctionner hors ligne » est la phrase la plus inutile d'un cahier des charges GMAO maritime. Tous les éditeurs répondront oui. Certains entendent par là une application embarquée complète, d'autres un cache de consultation en lecture seule, d'autres encore un formulaire mis en file d'attente qui perd la saisie si l'application se ferme.

La bonne méthode consiste à spécifier trois choses séparément : ce qui doit être consultable sans réseau, ce qui doit être créable ou modifiable sans réseau, et ce qui se passe à la resynchronisation. C'est le troisième point qui distingue vraiment les solutions. Deux mécaniciens, l'un à bord et l'autre à terre, modifient la même gamme pendant que le navire est hors couverture : que garde le système, que signale-t-il, à qui ?

Le piège classique

Accepter une démonstration en mode avion pendant trente secondes comme preuve. Le mode hors connexion se juge sur une traversée, pas sur une démo. Demandez explicitement la durée maximale d'autonomie hors réseau et le volume de données conservé localement.

Exigences à reprendre

  • OFF-01 — « Sans aucune connectivité, l'utilisateur embarqué devra pouvoir : consulter l'arborescence complète des équipements du navire et leurs documents attachés, consulter le plan de maintenance des [90] jours à venir, créer et clôturer un ordre de travail, saisir un relevé de compteur, déclarer une anomalie avec photo, et consulter le stock de pièces du bord. »
  • OFF-02 — « L'autonomie hors connexion devra être d'au moins [N] jours sans perte de saisie. Le soumissionnaire précisera le volume de données répliqué localement et le comportement de l'application en cas de saturation de l'espace de stockage du terminal. »
  • OFF-03 — « À la resynchronisation, le système devra détecter les modifications concurrentes portant sur le même objet, conserver les deux versions et signaler le conflit à un rôle désigné pour arbitrage. L'écrasement silencieux d'une saisie bord par une saisie terre sera considéré comme non conforme. »
  • OFF-04 — « Le soumissionnaire décrira le protocole de synchronisation, la bande passante consommée par une synchronisation quotidienne type, et la possibilité de synchroniser sur liaison satellite bas débit. »

Le référentiel équipements : profondeur, sisterships, reprise de l'existant

Le référentiel est le socle. Tout le reste — plan de maintenance, historique, pièces, coûts — s'y accroche. Une arborescence trop plate et vous ne saurez jamais si la panne récurrente vient du turbocompresseur ou du refroidisseur d'air de suralimentation. Une arborescence trop profonde et personne ne la remplit.

Trois exigences comptent vraiment. La profondeur de l'arborescence : navire, système, équipement, sous-ensemble, composant remplaçable, avec la possibilité de descendre au niveau de l'article suivi en numéro de série. La réplication sur sisterships : sur une flotte de ferries identiques, ressaisir le référentiel navire par navire représente des semaines de travail et garantit des divergences. Et la reprise de l'existant, presque toujours sous-estimée.

Le piège classique

Écrire « reprise des données existantes » sans dire dans quel format elles existent. Vos données sont dans un classeur de quarante onglets, un PDF scanné de la liste de machines du chantier, et la tête du chef mécanicien qui part à la retraite au printemps. Ces trois sources ne se reprennent pas de la même manière et n'ont pas le même coût. Dites lesquelles vous fournirez et sous quelle forme.

Exigences à reprendre

  • EQP-01 — « Le référentiel devra permettre une arborescence d'au moins [5] niveaux (navire, système, équipement, sous-ensemble, composant), avec attributs libres par niveau et rattachement d'un numéro de série, d'un fabricant et d'une documentation à chaque nœud. »
  • EQP-02 — « La solution devra permettre de dupliquer le référentiel et le plan de maintenance d'un navire vers un sistership, puis de gérer les écarts navire par navire sans rompre le lien avec le modèle de flotte. »
  • EQP-03 — « La reprise portera sur les sources suivantes : [fichiers tableur, listes de machines chantier, extraction de l'outil actuel, documentation fabricant]. Le soumissionnaire indiquera les formats d'import acceptés, le volume traitable, le nombre de reprises d'essai incluses, et qui, de l'éditeur ou du client, réalise le nettoyage des données. »

Plan de maintenance et déclencheurs : la partie que les outils génériques ratent

C'est la section qui sépare une GMAO maritime d'un outil conçu pour un site à terre. Ailleurs, la maintenance préventive est presque toujours calendaire. À bord, elle est mixte : le moteur principal se révise aux heures de fonctionnement, le matériel de sécurité à la date, les injecteurs à la combinaison des deux, et certains organes sur état mesuré. Si le cahier des charges ne décrit pas cette mixité, vous achèterez un agenda.

Le point qui coince le plus souvent est la combinaison de déclencheurs. « Toutes les 500 heures ou tous les 12 mois, au premier des deux termes échu, avec remise à zéro du compteur à la réalisation » est une règle banale à bord et impossible à exprimer dans beaucoup d'outils. Demandez une démonstration sur ce cas précis. Le second point est la tolérance : une échéance à 500 heures réalisée à 512 heures pendant une escale n'est pas un retard, c'est une réalisation dans la fenêtre admise, et le système doit savoir l'enregistrer comme telle.

Type de déclencheurExemple à bordCe que le système doit gérer
CalendaireInspection annuelle du matériel de sécurité SOLASDate fixe, récurrence, report avec justification tracée
Compteur d'heuresRévision d'un groupe électrogèneSaisie manuelle ou automatique du compteur, projection de la date d'échéance
Cycles et événementsNombre de démarrages, nombre de traits de chalut, nombre de manœuvres de guindeauCompteur incrémental non temporel
État mesuréAnalyse d'huile, relevé vibratoire, épaisseur d'anodeSeuil déclenchant une tâche, historisation de la mesure
Combiné500 h ou 12 mois, premier terme échuRègle multicritère, réinitialisation à la réalisation

Sur la construction du plan lui-même, notre guide en quatre étapes pour un plan de maintenance préventive détaille ce qui doit exister avant même d'ouvrir un logiciel.

Exigences à reprendre

  • PMS-01 — « La solution devra gérer des déclencheurs calendaires, à compteur d'heures, à cycles et sur seuil de mesure, ainsi que leur combinaison logique (ET / OU) sur une même tâche, avec réinitialisation automatique du compteur à la clôture de l'intervention. »
  • PMS-02 — « Chaque tâche devra porter une tolérance paramétrable exprimée en jours et/ou en heures de fonctionnement. Une intervention réalisée dans la tolérance ne devra pas être comptabilisée en retard dans les indicateurs. »
  • PMS-03 — « Une gamme de maintenance devra contenir a minima : les opérations détaillées, les pièces et consommables associés, la durée estimée, la qualification requise, les consignes de sécurité applicables et les documents de référence. »
  • PMS-04 — « Le report d'une échéance devra être tracé : auteur, date, motif, nouvelle échéance, et validation par un rôle habilité au-delà de [N] jours de report. »

La conformité : ISM, classification, certificats, Port State Control

C'est la section que les éditeurs non maritimes traitent par une phrase générique sur la « conformité réglementaire ». Elle mérite d'être la plus détaillée du document, parce que c'est là que se joue la différence entre un outil de confort et un outil qui vous évite une déficience.

Quatre blocs à couvrir. Les enregistrements exigés par le code ISM : le système de gestion de la sécurité impose de tenir la preuve de l'entretien du navire et de ses équipements, et cette preuve doit être produisible à l'audit. Les équipements critiques au sens du chapitre 10.3 du code, pour lesquels des mesures spécifiques et des essais périodiques sont attendus : le système doit permettre de les marquer comme tels et de les traiter différemment du reste. Le PMS approuvé par la société de classification, si votre flotte est concernée, avec ses contraintes propres de traçabilité et de rapport. Et les certificats, navire comme équipage, avec alertes d'expiration. Nos articles sur la conformité ISM appuyée sur une GMAO et sur le PMS approuvé par les sociétés de classification détaillent ces deux blocs.

Le piège classique

Se contenter d'exiger que « les données soient conservées ». Un inspecteur du Port State Control ne demande pas des données, il demande un dossier, sur un poste, en quelques minutes, souvent en anglais. Spécifiez la production du document, pas seulement le stockage.

Exigences à reprendre

  • CNF-01 — « La solution devra permettre d'identifier les équipements critiques au sens du chapitre 10.3 du code ISM, de leur associer des tâches et essais périodiques spécifiques, et d'éditer la liste de ces équipements avec l'état de leurs échéances à une date donnée. »
  • CNF-02 — « Le système devra produire, en moins de [5] minutes et sans intervention de l'éditeur, un dossier exportable au format PDF comprenant, pour un équipement ou un système donné : l'historique complet des interventions sur [période], les pièces remplacées, les intervenants et les documents joints. Ce dossier devra être disponible en français et en anglais. »
  • CNF-03 — « La solution devra gérer les certificats du navire et de l'équipage avec date d'émission, date d'expiration, fenêtre d'inspection, pièce jointe et alerte paramétrable à [90 / 60 / 30] jours, adressée à des destinataires distincts bord et terre. »
  • CNF-04 — « Le soumissionnaire précisera si sa solution est déjà utilisée dans le cadre d'un système de maintenance planifiée approuvé par une société de classification, et lesquelles. »

Stocks et achats : la liaison pièce-équipement avant tout

Une GMAO qui gère les stocks sans les rattacher aux équipements ne sert à rien de plus qu'un inventaire. La seule question qui compte à bord est : quelles pièces vont avec cette machine, et lesquelles ai-je réellement à disposition ? Le reste en découle.

Le second point spécifiquement maritime est la double localisation. Une pièce peut être au magasin du bord, dans un local du navire, au dépôt à terre, ou en transit vers le prochain port d'escale. Les quatre situations sont différentes et un modèle de stock mono-site ne les représente pas. Notre article sur la gestion des stocks MRO et les ruptures de pièces critiques développe la logique de seuils applicable aux pièces critiques.

Le piège classique

Oublier les pièces de rechange obligatoires imposées par la classification ou le pavillon. Elles ne se gèrent pas comme du consommable : elles doivent être identifiées comme obligatoires, leur consommation doit déclencher un réapprovisionnement suivi, et leur absence doit être visible avant la visite, pas pendant.

Exigences à reprendre

  • STK-01 — « Chaque article devra pouvoir être rattaché à un ou plusieurs équipements du référentiel, avec référence fabricant, référence interne et emplacement physique. Depuis la fiche d'un équipement, l'utilisateur devra accéder directement à la liste des pièces compatibles et à leur disponibilité par lieu de stockage. »
  • STK-02 — « La solution devra gérer des seuils d'alerte par article et par lieu de stockage, distinguer le stock embarqué du stock à terre, et permettre de marquer un article comme pièce de rechange obligatoire au titre de la classification ou du pavillon. »
  • STK-03 — « La clôture d'un ordre de travail devra décrémenter automatiquement le stock des pièces consommées et générer, le cas échéant, une demande d'approvisionnement rattachée à l'équipement et au navire concernés. »
  • STK-04 — « Le cycle d'achat devra couvrir : demande d'achat, circuit de validation à [N] niveaux avec seuils de montant, consultation fournisseurs, commande, réception partielle ou totale, et rapprochement avec la facture. »

Utilisateurs, rôles et traçabilité : le sujet des relèves

À bord, les comptes partagés deviennent la norme quand personne n'a spécifié le contraire. Un poste en machine, un identifiant collé sur l'écran, et tout l'historique devient inexploitable, en audit comme en analyse de panne. Le cahier des charges doit fermer cette porte dès le départ.

Le sujet propre au maritime est la relève. Un second mécanicien qui embarque pour six semaines doit hériter d'un rôle, pas d'un compte. Le système doit permettre d'attribuer et de retirer des droits en quelques secondes, sans supprimer l'historique de l'utilisateur sortant, et sans qu'un compte reste actif six mois après le débarquement.

Exigences à reprendre

  • USR-01 — « Chaque utilisateur devra disposer d'un compte nominatif. Les droits devront être attribués par rôle (chef mécanicien, second mécanicien, capitaine, superintendant, acheteur, auditeur en lecture seule) et modifiables navire par navire. »
  • USR-02 — « Toute création, modification ou suppression d'un enregistrement devra être horodatée et attribuée à un utilisateur identifié. L'historique devra être inaltérable : aucune suppression définitive ne doit être possible depuis l'interface, y compris pour un administrateur. »
  • USR-03 — « La clôture d'une intervention devra pouvoir exiger une validation par un rôle distinct de celui qui a réalisé le travail, avec signature électronique ou validation tracée, paramétrable par type de tâche. »
  • USR-04 — « La solution devra permettre la désactivation immédiate d'un compte au débarquement sans perte de l'historique attaché, et la reprise du rôle par l'utilisateur relevant. »

Les données : propriété, export, réversibilité, hébergement

Cette section s'écrit dans le cahier des charges, pas à la résiliation. Une fois le contrat signé, la position de négociation a disparu. Plusieurs années d'historique de maintenance sur toute une flotte représentent un actif technique considérable, et le jour où vous voudrez changer d'outil, la seule chose qui comptera sera ce que le contrat prévoit.

Quatre points. La propriété des données, qui doit être affirmée sans ambiguïté au bénéfice du client. Le format d'export, qui doit être structuré et exploitable, pas un PDF de plusieurs milliers de pages. La réversibilité en fin de contrat, avec un délai et un périmètre. Et l'hébergement, avec la localisation physique des serveurs et les modalités de sauvegarde. Si votre flotte relève d'exigences de cybersécurité de type IACS UR E26 et E27, ajoutez-les ici plutôt qu'en annexe.

Exigences à reprendre

  • DAT-01 — « Le client demeure propriétaire de l'intégralité des données saisies, importées ou générées, y compris les documents joints et les journaux d'audit. Le contrat ne devra conférer à l'éditeur aucun droit d'usage de ces données à d'autres fins que l'exécution du service. »
  • DAT-02 — « Le client devra pouvoir déclencher lui-même, à tout moment et sans coût supplémentaire, un export complet de ses données dans un format structuré et documenté, accompagné d'un dictionnaire de données, incluant les fichiers joints. »
  • DAT-03 — « En fin de contrat, quelle qu'en soit la cause, l'éditeur devra fournir l'export complet sous [30] jours et attester de la suppression des données à l'issue d'un délai de conservation de [90] jours. »
  • DAT-04 — « Le soumissionnaire précisera la localisation physique des données, la fréquence des sauvegardes, la durée de rétention, la procédure de restauration et le délai de restauration après incident. »

Intégration : ERP, comptabilité, paie, systèmes de bord

L'intégration est le poste où les mauvaises surprises coûtent le plus cher, parce qu'elle n'apparaît jamais dans les démonstrations. Deux familles à traiter séparément.

Côté gestion : l'ERP, la comptabilité, la paie. Ce qui circule, ce sont les commandes, les réceptions, les factures, les centres de coût par navire, et parfois les temps passés. Précisez le sens du flux et sa fréquence. Côté bord : les automates, les systèmes d'alarme et de surveillance, les passerelles de données. Récupérer automatiquement les compteurs d'heures depuis un bus NMEA 2000 supprime la source d'erreur la plus banale du plan de maintenance : le relevé manuel oublié ou mal recopié.

Le piège classique

Se contenter de la mention « API disponible ». Demandez la documentation publique de l'API, les limites d'appel, le mode d'authentification, et si l'accès est inclus dans l'abonnement ou facturé en supplément. Une API facturée au connecteur change l'économie du projet.

Exigences à reprendre

  • INT-01 — « La solution devra exposer une API documentée et accessible au client, permettant a minima la lecture des équipements, des ordres de travail, des mouvements de stock et des commandes. Le soumissionnaire fournira le lien vers la documentation publique et précisera les quotas d'appel. »
  • INT-02 — « Le soumissionnaire décrira les intégrations déjà réalisées avec [nom de l'ERP ou de l'outil comptable] et indiquera, pour chacune, s'il s'agit d'un connecteur standard maintenu ou d'un développement spécifique, ainsi que son coût. »
  • INT-03 — « La solution devra permettre l'alimentation automatique des compteurs d'heures depuis les systèmes de bord, ou à défaut par import de fichier planifié. »

Déploiement, formation et support : la section qu'on écrit trop vite

Le logiciel coûte rarement autant que le temps qu'il faut pour le mettre en service. Cette section doit répondre à trois questions simples : qui reprend les données, qui forme, et qui répond quand ça bloque à trois heures du matin heure de Marseille parce que le navire est au large de Singapour.

Le point le plus souvent négligé est le fuseau horaire du support. Un support « en heures ouvrées » depuis un seul pays ne couvre pas une flotte mondiale : pour une compagnie exploitant en Asie du Sud-Est, une plage 9h-18h heure de Paris tombe en pleine nuit à bord, c'est-à-dire précisément au moment où l'équipe de quart a besoin d'une réponse. Écrivez les heures en UTC, pas en « heures ouvrées ».

Exigences à reprendre

  • SUP-01 — « Le soumissionnaire précisera la répartition des tâches de reprise de données entre l'éditeur et le client, le nombre de jours d'accompagnement inclus, et le coût unitaire des jours supplémentaires. »
  • SUP-02 — « La formation devra couvrir les profils bord et terre séparément, en français et en anglais, et inclure un dispositif permettant de former un nouvel embarqué sans mobiliser l'éditeur. Le soumissionnaire indiquera le format (présentiel, distanciel, support écrit, vidéos) et la durée. »
  • SUP-03 — « Le support devra être joignable de [HH:MM] à [HH:MM] UTC, [N] jours par semaine, par [canaux]. Le soumissionnaire s'engagera sur un délai de première réponse de [N] heures et sur un délai de prise en charge des incidents bloquants de [N] heures, mesurés en heures calendaires et non en heures ouvrées. »
  • SUP-04 — « Le soumissionnaire décrira la procédure applicable lorsqu'un navire signale un dysfonctionnement alors qu'il est hors couverture réseau. »

Les erreurs classiques de mise en place viennent presque toutes de cette section traitée à la légère.

La trame du document, section par section

Un cahier des charges GMAO tient en quinze à trente pages. Au-delà, personne ne le lit en entier et les réponses deviennent approximatives. Voici la structure qui permet de dépouiller sans se perdre.

SectionContenu attenduErreur fréquente
1. Contexte et objectifsActivité, flotte, organisation technique, raison du projet, échéance viséeRédiger un argumentaire commercial au lieu d'un état des lieux
2. PérimètreNavires, pavillons, utilisateurs bord et terre, cible à trois ansCompter les navires et oublier les utilisateurs
3. Exigences fonctionnellesÉquipements, maintenance, stocks, achats, certificats, conformité, indicateursMélanger le besoin et la solution technique attendue
4. Exigences techniquesHors connexion, mobilité, intégration, données, hébergement, sécuritéÉcrire « doit fonctionner hors ligne » sans rien préciser
5. Exigences de serviceReprise de données, formation, support, délais engagés, réversibilitéTraiter le support en une ligne
6. Critères de notationGrille pondérée, exigences éliminatoires, méthode de notation, scénario de démonstrationNe pas communiquer la pondération aux soumissionnaires
7. Calendrier et modalitésDate limite de réponse, démonstrations, décision, mise en service ciblePrévoir une démonstration sans scénario imposé
8. AnnexesListe des navires, extrait du référentiel actuel, volumétrie, formats de donnéesNe rien joindre et demander un chiffrage ferme

Distinguer l'obligatoire du souhaitable

Chaque exigence doit porter un niveau : obligatoire (une réponse négative élimine le soumissionnaire), important (noté et pondéré), souhaitable (départage à égalité). Sans cette distinction, tous les éditeurs répondent « oui » partout et vous n'avez plus rien à comparer. Trois ou quatre exigences éliminatoires suffisent : au-delà, vous n'aurez plus de candidats.

Numéroter, toujours

Les codes du type PER-01 ou OFF-03 utilisés dans cet article ne sont pas décoratifs. Ils permettent d'exiger que chaque soumissionnaire réponde exigence par exigence, dans l'ordre, avec un niveau de couverture et un commentaire. Un éditeur qui répond par une plaquette commerciale au lieu d'un tableau ligne à ligne vous dit déjà quelque chose sur la suite de la relation.

Pondérer les critères et dépouiller les réponses

La pondération se fixe avant de recevoir les réponses, et se communique aux soumissionnaires. C'est ce qui garantit qu'on ne réajuste pas les poids après coup pour faire gagner celui qu'on préférait. Voici une répartition de départ, à ajuster selon la flotte : une compagnie de pêche hauturière montera le poids du hors connexion, un armateur de ferries celui de la conformité et de la disponibilité.

DomainePoids indicatifCe qu'on noteExigence éliminatoire possible
Couverture fonctionnelle maintenance20 %Déclencheurs combinés, gammes, tolérances, historiqueAbsence de déclencheur à compteur d'heures
Fonctionnement hors connexion15 %Périmètre créable hors réseau, gestion des conflits, autonomieAucune création d'ordre de travail hors réseau
Conformité et certificats15 %Équipements critiques, production du dossier d'audit, alertes d'expirationImpossibilité d'exporter un dossier d'historique
Référentiel et reprise de données10 %Profondeur, sisterships, formats d'import, effort de reprise
Stocks et achats10 %Liaison pièce-équipement, seuils, multi-lieux, circuit de validation
Ergonomie et adoption à bord10 %Nombre d'actions pour clôturer un ordre de travail, usage mobile, langues disponibles
Données, hébergement, réversibilité8 %Propriété, export autonome, localisation, sauvegardeRefus de garantir l'export complet
Support et formation7 %Couverture horaire en UTC, délais engagés, langues
Intégration5 %API documentée, connecteurs existants, coût
Coût complet sur [5] ansNoté à partLicences, mise en service, reprise, formation, options, ajout de navire

Noter sur une échelle courte

Une échelle à quatre niveaux suffit et évite les demi-points de complaisance : 0 non couvert, 1 couvert partiellement ou par contournement, 2 couvert en standard, 3 couvert en standard et démontré sur votre propre jeu de données. Le niveau 3 ne s'accorde qu'après démonstration sur un scénario que vous avez écrit vous-même. Par exemple : créer hors réseau un ordre de travail sur un auxiliaire, y consommer deux pièces, resynchroniser, puis éditer le dossier d'historique de l'équipement.

Le coût se note à part

Ne noyez pas le prix dans la grille fonctionnelle. Demandez un coût complet sur cinq ans : abonnement, mise en service, reprise de données, formation initiale et de rattrapage, options, coût d'ajout d'un navire, coût d'ajout d'un utilisateur. C'est le seul moyen de comparer une offre à faible abonnement et forte prestation de démarrage avec une offre construite à l'inverse. Notre analyse du vrai coût d'un tableur face à une GMAO maritime donne le cadre de raisonnement pour construire ce total.

Où se situe cette étape dans votre projet

Le cahier des charges est la deuxième des trois étapes d'un projet GMAO. Il ne sert pas à grand-chose si les deux autres sont sautées.

Avant : comparer les solutions du marché et comprendre ce qui distingue réellement une GMAO maritime d'un outil générique. Si vous en êtes encore là, commencez par notre grille de 32 critères pour choisir un logiciel de GMAO maritime : elle vous dira quoi regarder avant d'écrire quoi que ce soit.

Après : déployer. Une fois l'éditeur retenu, le projet se joue sur la reprise des données, l'appropriation par les équipages et les premières semaines d'usage réel. Notre check-list de mise en place d'une GMAO maritime reprend le fil à partir de la signature.

Un dernier conseil de méthode : faites relire le document par un chef mécanicien avant de l'envoyer. C'est lui qui saisira les données tous les jours, et c'est cette relecture qui fait disparaître les exigences théoriques que personne n'utilisera jamais. Si vous voulez confronter votre projet de cahier des charges à des cas réels de flottes de pêche, de ferries, de pilotage ou de navires de service, écrivez-nous.

Une fois le cahier des charges rédigé, la sélection puis le déploiement suivent une logique que nous déroulons pas à pas dans le guide complet de la GMAO maritime.

Partagez ce post sur les réseaux sociaux

Découvrez plus de conseils

DUERP à bord : le document unique des navires, sans le classeur

Ce que le DUERP impose à un armateur, ce qu'un auditeur ISM ou un inspecteur y cherche, et comment le tenir vivant depuis la GMAO plutôt que dans un classeur.

Lire l'article

Application de maintenance yacht : les besoins réels

Rotations d'équipage, budgets refit, conformité pavillon, reporting propriétaire : ce qu'une application de maintenance yacht doit vraiment savoir faire.

Lire l'article

Logiciel de planification de passage au bassin

Construire la spécification de passage au bassin depuis l'historique de maintenance, contrôler les avenants chantier et capitaliser pour le cycle suivant.

Lire l'article

Abonnez-vous à notre newsletter !

Nous communiquons régulièrement sur nos réseaux sociaux et via notre newsletter afin que vous soyez informé des nouveautés du logiciel.