Tout éditeur de logiciel maritime affirme « prendre en charge la conformité ». La plupart veulent dire un dossier de PDF et une colonne de dates. La différence entre cela et un logiciel qui maintient réellement une opération prête pour l'audit n'est pas une fonctionnalité — c'est une décision d'architecture prise dès le premier jour. Nous l'appelons la conformité dès la conception, et c'est le premier pilier de tout ce que nous construisons.
Le piège du module rapporté
Le cycle de vie typique d'un module de conformité ressemble à ceci : on construit un produit pour gérer les opérations, un client échoue à une inspection, et un « onglet conformité » est ajouté en un sprint. Le résultat est une comptabilité parallèle — le logiciel dit une chose, la réglementation en exige une autre, et un humain les réconcilie dans un tableur.
L'échec est structurel. Des réglementations comme la STCW (amendée par Manille 2010) et la MLC 2006 ne sont pas des listes de documents ; ce sont des systèmes de règles qui dépendent du grade, du service, du type de navire, de l'État du pavillon et du temps. Un maître d'équipage et un second mécanicien ne portent pas les mêmes certificats. Un certificat valide sous un pavillon peut exiger un visa sous un autre. Un certificat médical a un cycle de validité différent de celui d'un brevet d'aptitude. Si votre modèle de données ignore ces distinctions, aucune interface ne le rattrapera.
À quoi ressemble la conformité « native »
En pratique, la conformité dès la conception signifie que la logique réglementaire vit dans la couche de données et que tout le reste en dérive :
- Les exigences sont définies par grade. Le système sait quel ensemble de documents s'applique à chaque grade et catégorie de flotte — pont contre machine, marine marchande contre offshore — au lieu d'une liste générique pour tous.
- L'expiration est un état calculé, pas stocké. « Valide », « bientôt expiré » et « expiré » sont calculés en continu à partir des dates d'émission, des cycles de validité et des fenêtres d'alerte configurables — jamais saisis à la main.
- La vérification laisse une trace. Qui a vérifié un document, quand, contre quel registre et avec quel résultat est enregistré comme donnée de premier ordre. Un auditeur doit pouvoir reconstituer chaque décision.
- Le catalogue est de la donnée, pas du code. Quand une administration du pavillon met à jour une exigence, c'est le catalogue de règles qui change — pas le code source. La réglementation évolue plus vite que les cycles de release.
| Question | Conformité rapportée | Conformité dès la conception |
|---|---|---|
| Qui sait quels documents exige un grade ? | L'utilisateur, de mémoire | Le modèle de données |
| Que se passe-t-il quand une règle change ? | Une nouvelle release, un jour | Une mise à jour du catalogue |
| Pouvez-vous prouver qui a vérifié quoi ? | Parfois, dans les e-mails | Toujours, dans la piste d'audit |
| Quand découvrez-vous un certificat expiré ? | À l'inspection | Trente jours avant |
Pourquoi c'est un enjeu commercial, pas seulement technique
Dans les secteurs réglementés, un logiciel vaut ce que vaut son pire audit. Une opération de crewing qui découvre un certificat expiré pendant une inspection de l'État du port se moque de l'élégance du tableau de bord. Les systèmes conçus autour de la réglementation transforment la conformité d'une urgence récurrente en un processus de fond — et c'est un coût opérationnel mesurable, pas une abstraction : moins de détentions, moins de relèves d'équipage de dernière minute, moins de contrats perdus pour de la paperasse.
Le Panama abrite le plus grand registre de navires au monde, et l'écart entre l'exigence réglementaire et l'outillage opérationnel y est énorme. Cet écart est précisément notre terrain de travail.
À retenir
- La conformité ajoutée après coup finit toujours en comptabilité parallèle.
- STCW/MLC sont des systèmes de règles — grade, pavillon, temps — pas des listes de documents.
- Les expirations doivent être calculées, la vérification doit laisser une trace, les règles doivent vivre dans les données.
- La valeur commerciale d'un logiciel de conformité se mesure à l'audit, pas à la démo.
Vous travaillez dans un secteur réglementé et vous vous débattez avec les problèmes décrits ici ? Nous construisons des logiciels exactement pour cela.
Parler à PBS