> ## Content Index > Fetch the complete content index at: https://blog.olymbe.fr/llms.txt > Use this file to discover other available public pages before exploring further. # Obtenir une certification Class IIa quand l’architecture brûle encore - URL: https://blog.olymbe.fr/obtenir-une-certification-class-iia-quand-larchitecture-brule-encore/ - Published: 2026-07-10T00:06:00.000Z - Updated: 2026-07-10T00:07:29.000Z - Description: Comment reprendre un projet logiciel médical mal cadré, réaligner architecture, cybersécurité, CI/CD, documentation et dossier technique pour viser une certification Class IIa dans une startup sous contrainte. - Author: Alexandre RIPOLL - Tags: Architecture logicielle, Certification, Class IIa, Dette technique, Startup, Dossier technique, Cybersécurité, Kubernetes, Gouvernance IT, Dispositif médical, CI/CD Pour poser le décor : en juin 2024, je rejoins une petite startup éditrice d’un logiciel médical, en tant qu’architecte logiciel et responsable des développements. L’entreprise traverse alors une période de restructuration, marquée par un turn-over important des équipes techniques, des retards critiques dans l’obtention de la certification médicale européenne Class IIa, et une pression budgétaire déjà bien installée. Cette certification n’est pas un sujet secondaire : elle conditionne directement la capacité de l’entreprise à poursuivre son activité dans des conditions viables. Ma mission initiale semblait claire sur le papier : reconstruire une équipe minimale, reprendre le développement du logiciel en cours de certification, sécuriser la trajectoire technique, et accompagner les audits de l’organisme notifié sur les processus IT comme sur le logiciel lui-même. Comme souvent dans ce genre de contexte, le papier était plus calme que la réalité. Très vite, le sujet n’a plus seulement été de “continuer le développement”. Il a fallu comprendre ce qui avait été construit en l'absence "des sachants", ce qui avait été déclaré, ce qui était réellement déployé, ce qui pouvait être défendu devant un auditeur, et ce qui relevait davantage de l’optimisme documentaire que de l’architecture maîtrisée. ## Le symptôme visible À mon arrivée, le problème ne se présentait pas sous la forme noble d’un “chantier d’architecture”. Il ressemblait plutôt à une startup en restructuration, une équipe réduite à reconstruire, un budget déjà très consommé, un dossier technique censé porter une certification Class IIa, et une plateforme qui avait manifestement évolué plus vite que sa propre capacité à être comprise. Sur le papier, tout devait être presque prêt. Dans la réalité, beaucoup d'optimisme avait été vendu à la direction et rien n’était vraiment aligné. Le dossier technique décrivait une intention. L’architecture en production racontait une autre histoire. Les pipelines CI/CD étaient partiels, parfois incohérents avec ce qui était déclaré, parfois dépendants d’images custom non documentées. L’infrastructure Kubernetes existait, oui, mais exister n’est pas être maîtrisée. Les déploiements fonctionnaient jusqu’au jour où ils ne fonctionnaient plus. Les environnements avaient leurs habitudes, leurs contournements, leurs secrets implicites. Ce genre de système a une particularité : il donne longtemps l’impression d’être vivant, alors qu’il est dans une lente agonie, en train de perdre sa maintenabilité. L’application mélangeait plusieurs mondes techniques dans un même monorepo : du React, du JavaScript avec un framework custom, des microservices Java 21, un monolithe legacy Java 8, le tout poussé vers des infrastructures Kubernetes. Ce n’est pas forcément un problème en soi. Un monorepo peut être une très bonne décision. Kubernetes peut être une très bonne plateforme. Java 21 peut être un excellent socle. Même un monolithe legacy peut rester parfaitement respectable. Le problème commence lorsque tout cela cohabite sans vision claire, sans règles communes, sans ownership explicite, sans documentation exploitable, sans cartographie des assets, sans stratégie de migration, sans modèle de sécurité robuste, sans respect des bonnes pratiques, sans compréhension des outils et structures et, surtout, sans correspondance fiable avec le dossier technique censé soutenir la certification. À ce stade, la dette technique n’est plus seulement du code à nettoyer. Elle devient une dette de preuve. Et dans un contexte de certification, une dette de preuve coûte souvent plus cher qu’une dette de développement. Les symptômes étaient nombreux : - une documentation technique absente, obsolète ou contradictoire ; - un dossier technique qui ne reflétait pas fidèlement l’architecture réelle ; - une cybersécurité traitée trop tard, voire inexistante, comme une annexe oubliée, alors qu’elle aurait dû structurer les choix dès le départ ; - une infrastructure fragile, avec des failles évidentes et des zones non maîtrisées ; - aucun inventaire d’assets correctement tenu ; - des pipelines CI/CD incomplets, non traçables ou dépendants de composants non justifiés, voire manquants ; - des patterns applicatifs hétérogènes ; - une séparation insuffisante entre legacy, nouveaux services et composants expérimentaux ; - une maitrise inexistante de kubernetes, de ses usages et de ses bonnes pratiques ; - des demandes nécessaires à la certification qui n’avaient pas été identifiées ou déclarées correctement au départ ; - des temps de réponse très longs de l’organisme notifié, incompatibles avec la réalité financière d’une startup sous tension. Le symptôme visible, c’était donc une équipe ralentie, une architecture difficile à défendre, une roadmap qui se faisait avaler par la remédiation et une certification qui avançait au rythme d’un départ en vacances coincé dans une voiture en pleine canicule sur les autoroutes des vacances. Mais le vrai problème était plus profond. --- ## La cause réelle La cause réelle n’était pas que “le code était mauvais”. Cette phrase est trop simple, trop confortable, et souvent injuste bien que vraie ici. Le code reflète rarement uniquement le niveau des développeurs. Il reflète surtout le cadre dans lequel ils ont travaillé. Ici, l’ancienne équipe avait été largement livrée à ses choix techniques, sans gouvernance suffisamment forte, sans arbitrages d’architecture consolidés, sans vision à long terme claire, sans compréhension claire des outils et de leurs utilité, et probablement avec une pression constante pour produire rapidement. Dans beaucoup de startups, on confond vitesse et absence de structure. Au début, cela donne une impression de liberté. Chacun peut choisir son outil sans le maitriser, son pattern, sa manière de livrer, son découpage, ses dépendances, sa stratégie de build. Puis le produit grandit. Les contraintes réglementaires arrivent. La certification impose de prouver ce qui était seulement supposé. Et soudain, l’absence de structure n’est plus de l’agilité : c’est un passif. La première cause profonde était donc l’absence de gouvernance technique. Pas au sens bureaucratique du terme. Je ne parle pas de comités interminables, de documents Word qui dorment dans SharePoint ou de réunions où l’on débat du nommage des branches Git pendant des heures... Je parle d’une gouvernance minimale, saine, utile par une ou des personne(s) compétante(s) : - qui décide des standards techniques ; - qui valide les architectures structurantes ; - qui documente les exceptions ; - qui relie les choix logiciels aux exigences produit, sécurité et réglementaires ; - qui garantit qu’un système critique reste compréhensible par d’autres que ceux qui l’ont créé. La deuxième cause était le décalage entre le produit réel et le dossier technique. Dans un projet soumis à certification, le dossier technique ne doit pas être une brochure élégante décrivant une version idéalisée du logiciel. Il doit être la traduction maîtrisée du système réel : architecture, exigences, risques, composants, dépendances, mesures de sécurité, traçabilité, tests, processus de livraison, maintenance, surveillance. Quand le dossier technique et l’architecture divergent, il ne s’agit pas d’une simple incohérence documentaire. C’est un signal de perte de contrôle. La troisième cause était la cybersécurité traitée comme un sujet périphérique. C’est une erreur classique. On construit d’abord le produit, on branche l’infrastructure, on met une CI/CD, on ouvre des accès, on ajoute Kubernetes parce que “ça scale”, puis on se demande plus tard comment sécuriser l’ensemble. La sécurité ne pardonne pas cette approche. Elle impose de savoir ce qui existe, où cela tourne, qui y accède, comment les secrets sont gérés, quelles surfaces sont exposées, quels flux sont autorisés, quels composants sont vulnérables, comment les incidents sont détectés, comment les journaux sont conservés, et comment l’ensemble est prouvé. Sans inventaire d’assets à jour, la cybersécurité devient une fiction. La quatrième cause était l’accumulation de choix techniques contradictoire, sans maitrise des stacks techniques choisie ni vision d'ensemble. Un monorepo hétérogène n’est pas une faute. Des microservices ne sont pas une faute. Kubernetes n’est pas une faute. Un legacy Java 8 n’est pas une faute. La faute, c’est l’absence de stratégie explicite autour de ces choix et une roadmap précise. Pourquoi ce service est-il isolé ? Pourquoi garder un monolithe ? Pourquoi et comment mettre un monolithe sur kubernetes ? Pourquoi Java 21 ici et Java 8 là ? Pourquoi ce framework custom existe-t-il encore ? Qui maintient les images CI custom ? Quel est le cycle de migration ? Quels composants sont critiques pour la certification et pourquoi ? Quelles parties doivent être stabilisées avant audit ? Quelles parties peuvent attendre ? Quel est l'ordre de bataille pour rattraper la dette technique et mettre l'application et le SI à niveau ? Sans réponses, l’architecture devient une collection de décisions orphelines. Et une décision technique orpheline finit toujours par demander une pension alimentaire. --- ## Ce que l’architecture révélait vraiment Une architecture ne ment jamais très longtemps. Elle révèle les priorités réelles de l’organisation, bien plus que les présentations stratégiques. Dans ce cas, l’architecture révélait une tension permanente entre ambition produit, contrainte réglementaire, turnover, manque de vision et de connaissance des outils, et absence de cadre initial clair. Elle racontait une entreprise qui avait voulu aller vite, qui avait de l'ambition, mais qui n’avait pas su s'entourer, à certains moments, des bons profils pouvant challenger les décisions, comprendre les outils et avoir une vision d'ensemble cohérente pour construire les fondations nécessaires à un logiciel destiné à porter une certification exigeante. Le système disait plusieurs choses. D’abord, il disait que la startup avait confondu construction d'un MVP et construction d’un produit certifiable. Ce ne sont pas les mêmes exercices. Un prototype peut vivre avec de l’implicite. Un produit certifiable ne le peut pas. Un MVP peut accepter des raccourcis. Un dispositif logiciel soumis à un dossier technique robuste doit savoir expliquer ses raccourcis, les limiter, les tracer, les tester, les sécuriser et les corriger. Ensuite, l’architecture disait que l’organisation avait externalisé trop de décisions structurantes vers l’équipe technique sans lui donner le cadre nécessaire. L’autonomie est précieuse. Mais l’autonomie sans doctrine devient une loterie. Chaque développeur peut faire un choix rationnel localement, et produire collectivement un système incohérent. C’est même l’un des grands pièges de l’ingénierie logicielle : beaucoup de décisions raisonnables prises séparément peuvent créer une architecture déraisonnable lorsqu’elles sont assemblées. Enfin, l’architecture révélait que la dette technique avait été sous-estimée dans sa dimension organisationnelle. On parle souvent de dette technique comme si elle se limitait à du code ancien, des dépendances obsolètes ou des tests manquants. En réalité, la dette la plus coûteuse était ailleurs : - dette de documentation ; - dette de traçabilité ; - dette de sécurité ; - dette d’exploitation ; - dette de gouvernance ; - dette de conformité ; - dette de transmission entre équipes ; - dette d'utilisation d'outils sans adaptation du logiciel à leurs natures. La certification Class IIa ne crée pas ces dettes. Elle les expose. Elle agit comme une lumière sur ces zones d'ombres qui étaient déjà fragiles. Et c’est là que les choses deviennent difficiles pour une startup : on ne peut plus simplement dire “on corrigera plus tard”. Le “plus tard” arrive avec un auditeur, un organisme notifié, des délais de réponse imprévisibles, et une trésorerie qui n’a aucune patience pour les élégances méthodologiques. --- ## Les options sur la table Face à une situation de ce type, il y a rarement une solution parfaite. Il y a des options imparfaites, chacune avec son coût, son risque et sa part d’inconfort. ### Option 1 : tout réécrire proprement C’est l’option qui fait rêver les ingénieurs fatigués. On repart sur une architecture claire. On découpe proprement. On supprime le legacy. On documente tout. On remet les bons patterns. On reconstruit les pipelines. On refait la sécurité. On aligne enfin le produit, le code et le dossier technique. Sur le papier, c’est magnifique. Dans une startup en budget très limité, avec une certification en cours, c’est souvent suicidaire. Une réécriture complète a 4 défauts majeurs : - elle consomme énormément de temps avant de produire de la valeur certifiable ; - elle introduit de nouveaux risques fonctionnels ; - elle crée une période dangereuse où l’ancien système est encore nécessaire et le nouveau pas encore prouvable. - elle demande la réécriture et la resoumission d'un dossier technique complet. Réécrire peut être nécessaire dans certains contextes. Mais dans celui-ci, ce n’était pas une stratégie mais un suicide, une liquidation pure et simple de l'entreprise. ### Option 2 : ne rien toucher et corriger uniquement le dossier technique C’est l’option inverse. On laisse le système tel quel, et on tente de faire rentrer la réalité dans la documentation. C’est tentant quand le budget est bas et que les délais sont serrés. C’est aussi très dangereux. Un dossier technique ne doit pas maquiller l’architecture. Il doit la représenter fidèlement. Si le système est fragile, non sécurisé ou incohérent, la documentation ne le rendra pas robuste. Elle ne fera que déplacer le risque vers l’audit, la maintenance, l’exploitation ou l’incident de production. Cette option aurait probablement permis de gagner quelques semaines à court terme. Elle aurait coûté beaucoup plus cher ensuite. ### Option 3 : figer le périmètre, stabiliser l’existant, reconstruire les preuves C’est l’option la moins glamour, mais souvent la plus intelligente. Elle consiste à accepter que l’on ne pourra pas tout refaire, ni tout corriger immédiatement, mais que l’on doit reprendre le contrôle sur les zones critiques. L’objectif n’est pas de rendre le système parfait. L’objectif est de le rendre maîtrisable, explicable, sécurisable et défendable. Cela implique : - de figer ou réduire le périmètre fonctionnel non essentiel ; - de cartographier les composants réellement en production ; - de reconstruire l’inventaire des assets ; - de réaligner le dossier technique avec l’architecture réelle ; - de prioriser les failles de sécurité selon le risque ; - de documenter les pipelines CI/CD et leurs dépendances ; - de clarifier les responsabilités ; - de définir les patterns acceptables ; - de tracer les écarts et les plans de remédiation ; - de distinguer ce qui doit être corrigé avant certification de ce qui peut être planifié après. Cette option impose de renoncer à l’illusion du grand nettoyage. Elle impose aussi énormément de travail et de nuits blanches, dans un contexte de deadline serrée. Mais elle a un avantage décisif : elle fonctionne dans le monde réel. ### Option 4 : repousser la certification C’est parfois la décision la plus saine. Mais dans une startup, repousser une certification peut signifier repousser le marché, repousser le revenu, repousser les financements, dégrader la confiance des investisseurs, et fragiliser encore plus l’équipe. Il faut donc distinguer deux choses : - repousser parce qu’on découvre tardivement que le système n’est pas prêt ; - repousser parce qu’on a établi lucidement qu’un passage en force serait plus dangereux que le délai lui-même. Dans notre cas, l’enjeu était de réduire l’incertitude, pas de rêver un calendrier idéal. --- ## La décision prise La décision retenue a été une approche de reprise contrôlée. Pas une réécriture totale. Pas un simple maquillage documentaire. Pas une fuite vers une nouvelle architecture parfaite qui n’aurait jamais atteint l’audit à temps. L’objectif était de reprendre la maîtrise par couches. D’abord, il fallait établir une vérité technique. Sur le papier, cela paraît simple. En pratique, cela fut très complexe. La première étape a consisté à comprendre ce qui existait réellement : applications, services, versions Java, composants front, images docker, artefacts, dépendances, environnements Kubernetes, flux réseau, secrets, bases de données, points d’exposition, scripts de build, pipelines, branches, pratiques de déploiement. On ne peut pas sécuriser ce que l’on ne connaît pas et on ne peut pas certifier ce que l’on ne sait pas expliquer. Ensuite, il fallait reconstruire l’alignement entre dossier technique et architecture. Cela signifiait reprendre les écarts un par un : - ce qui était décrit mais absent ; - ce qui existait mais n’était pas décrit ; - ce qui était décrit différemment de la réalité ; - ce qui avait évolué sans mise à jour documentaire ; - ce qui avait été supposé conforme sans preuve suffisante. Cette étape est ingrate. Elle produit peu de fonctionnalités visibles, elle a tendance à plutôt mettre d'aplomb des fonctionnalités décrite dans le DT (dossier technique). Elle ne fait pas rêver un comité produit. Elle ne se vend pas bien dans une roadmap. Mais elle est fondamentale. Parce qu’à partir du moment où l’on peut expliquer le système, on peut commencer à le gouverner. La cybersécurité a ensuite été replacée au centre du sujet. Pas comme un supplément d’âme. Comme une condition d’existence. Cela passait par une approche pragmatique : - identifier les surfaces exposées ; - revoir et lister les accès ; - documenter les flux ; - clarifier la gestion des secrets ; - traiter les failles les plus critiques, pas que du produit, mais aussi de l'infrastructure du SI ; - mettre en place ou renforcer l’observabilité ; - Mettre en place et consolider les sauvegardes et procédures d’exploitation ; - intégrer la sécurité dans les pipelines ; - produire des preuves exploitables ; - mettre en place une roadmap crédible pour corriger ce qui peut l'être et justifier plus tard. Dans un monde idéal, tout aurait été conçu ainsi dès le premier jour. Dans le monde réel, on reprend parfois un système qui a déjà pris l’autoroute à pleine vitesse, sans ceinture, sans contrôle technique, avec un voyant moteur allumé depuis six mois et, parfois, sans conducteur réveillé. Il faut prioriser. La priorité n’est pas de mettre un coup de tampon sur un papier, de boucler une ceinture et de mettre une gommette sur le tableau de bord. La priorité est d’éviter la sortie de route, de reprendre la maîtrise et le contrôle du véhicule, de réduire la vitesse et de montrer la connaissance des défauts et tenir un planning de correction. Sur la partie CI/CD, la décision a été reprendre le contrôle des images orpheline, terminer et sécurisé la pipeline de production sur une version minimum. Une image custom non expliquée, ni historisé est un risque. Un build reproductible seulement sur la machine d’un ancien développeur est un risque industriel déguisé en détail technique. Il fallait donc identifier les chaînes de build, documenter les images utilisées, supprimer ou encadrer les dépendances opaques, rapprocher les pipelines de ce qui était déclaré dans le dossier technique, ajouter des couche de vérification de sécurité, et rendre les livraisons plus traçables. Concernant le monorepo, l’approche n’a pas été dogmatique. Le réflexe facile aurait été de dire : “il faut tout découper”. Mais découper un système que l’on ne maîtrise pas encore, dans un calendrier très tendu, peut aggraver le problème. La première étape a donc été de clarifier les frontières logiques : ce qui appartient au legacy, ce qui relève des services modernes, ce qui est critique pour la certification, ce qui est expérimental, ce qui doit être maintenu, ce qui doit être migré, ce qui doit être isolé. Un mauvais découpage physique ne se corrige pas toujours par un découpage précipité. Parfois, il faut d’abord remettre à niveau une architecture bancale avant de reconstruire une architecture conceptuelle claire et de toucher à la structure des repositories ou des services. Enfin, il a fallu reconstruire une équipe minimale mais capable de porter le chantier. Dans une situation de budget serré, on n’a pas le luxe d’empiler les rôles. Il faut des profils capables de comprendre le code, l’infrastructure, les exigences qualité, les contraintes réglementaires, la sécurité, et les priorités produit. Il m'a fallu également remonter les manches et porter l'un de sujet les plus sensible, à savoir la migration du legacy sur une stack récente et homogène, seule pour permettre de composer avec ce budget serré, cette équipe réduite, ces chantiers énormes et ce calendrier plus que serré. Ce n’est pas confortable. Mais c’est souvent la réalité d’une startup en phase critique. La décision acceptait donc plusieurs risques : - tout ne serait pas corrigé immédiatement ; - certaines dettes seraient documentées et planifiées plutôt que supprimées ; - certaines zones legacy resteraient en place temporairement sur du moyen termes ; - certaines ambitions produit devraient attendre ; - l’équipe travaillerait sous forte contrainte ; - j'aurais la nécessité d'assurer plusieurs rôles ; - la certification dépendrait aussi de délais externes difficiles à maîtriser. Mais elle réduisait le risque principal : continuer à avancer sans savoir exactement sur quoi reposait le système. --- ## Ce que j’aurais aimé savoir avant 1. J’aurais aimé savoir qu’un dossier technique initial peut donner une impression de maturité très trompeuse. 2. Un document bien présenté ne garantit pas que l’architecture est maîtrisée. 3. Il peut exister un écart massif entre la version racontée du système et sa version réelle. Et plus cet écart est découvert tard, plus il coûte cher. 4. J’aurais aimé savoir que la certification ne teste pas seulement le produit, mais également l’organisation et les processus de gestion qui produise le produit. 5. Elle révèle la qualité du delivery, la rigueur documentaire, la capacité à tracer une décision, la maîtrise des dépendances, la cohérence des environnements, la discipline de sécurité, la robustesse de l’exploitation, et la capacité de l’équipe à expliquer ce qu’elle fait. 6. J’aurais aimé savoir que la dette technique la plus dangereuse n’est pas toujours dans le code. 7. Une classe mal nommée peut être moins grave qu’une image CI custom non documenté et impossible à reproduire. 8. Un service mal découpé peut être moins urgent qu’une absence d’inventaire des assets. 9. La dette qui tue une certification est souvent celle que personne ne voit dans l’IDE. 10. J’aurais aimé savoir qu’un organisme notifié peut devenir un facteur de risque projet voir organisationnel à part entière. Parce que ses délais de réponse, ses demandes complémentaires, ses interprétations et ses cycles d’échange peuvent peser très lourd dans une startup. Quand le budget est serré, chaque semaine d’attente devient une décision financière. Chaque clarification tardive devient une dette de planning. 11. J’aurais aimé savoir que l'absence de documentation des compromis dès le moment où ils sont pris, peut être un risque énorme pour le future d'une boite. 12. Une décision non documentée finit toujours par être réinterprétée. Et dans une certification, l’oubli est rarement considéré comme une stratégie acceptable. 13. J’aurais aimé savoir, enfin, qu’il ne faut jamais sous-estimer la fatigue d’une équipe qui reprend un système mal tenu. Corriger du code est une chose. Reprendre la responsabilité d’un produit critique, sous budget limité, avec une certification en ligne de mire, une architecture incohérente, une documentation faible, des attentes fortes et des délais externes imprévisibles, c’est autre chose. Ce n’est pas seulement un sujet technique. C’est un sujet de lucidité collective, un éffort commun et une préssion énorme sur l'ensemble de la boite. --- ## Checklist pour éviter le même piège Avant de viser une certification Class IIa avec un logiciel existant, je recommande de passer par une checklist froide, presque brutale. ### 1\. Vérifier l’alignement entre produit réel et dossier technique - Le dossier technique décrit-il l’architecture réellement déployée ? - Les composants mentionnés existent-ils toujours ? - Les composants existants sont-ils tous décrits ? - Les flux de données sont-ils documentés et vérifiables ? - Les environnements de build, test, préproduction et production sont-ils cohérents avec ce qui est déclaré ? - Les écarts sont-ils tracés, justifiés et planifiés ? ### 2\. Reconstituer l’inventaire des assets - Applications ; - services ; - repositories ; - images Docker ; - clusters Kubernetes ; - namespaces ; - bases de données ; - buckets ; - certificats ; - secrets ; - comptes techniques ; - dépendances externes ; - outils CI/CD ; - outils de supervision ; - endpoints exposés ; - fournisseurs cloud ; - accès administrateurs ; - outils commerciale ; - outils de gestion ; - OS utilisé ; - Outils utilisé par les différentes équipes (déceloppeur, testeur, infrastructure, etc). Sans inventaire, il n’y a pas de maîtrise. Sans maîtrise, il n’y a pas de sécurité sérieuse. ### 3\. Auditer la chaîne CI/CD - Les pipelines sont-ils complets ? - Les images utilisées sont-elles documentées ? - Les builds sont-ils reproductibles ? - Les artefacts sont-ils versionnés ? - Les secrets sont-ils correctement gérés ? - Les scans de dépendances et d’images existent-ils ? - Les scans de sécurité et détection des CVE existent-ils ? - Les déploiements sont-ils traçables ? - Le processus correspond-il à ce qui est décrit dans le dossier technique ? Une CI/CD fragile est une usine à incertitude. ### 4\. Traiter la cybersécurité comme une exigence d’architecture - Cartographier les surfaces exposées ; - fermer les accès inutiles ; - documenter les flux ; - revoir les droits ; - renforcer la gestion des secrets ; - corriger les vulnérabilités critiques ; - activer les logs pertinents ; - prévoir les sauvegardes ; - formaliser les procédures d’incident et de reprise ; - formaliser les procédures de maintien en condition opérationnel (entre l'infrastructure et la cyber) ; - intégrer les contrôles dans le delivery. La sécurité ajoutée après coup ressemble souvent à une porte blindée montée sur une cloison en plâtre. ### 5\. Clarifier les responsabilités - Qui possède chaque service ? - Qui maintient le legacy ? - Qui valide les choix d’architecture ? - Qui met à jour le dossier technique ? - Qui répond aux demandes de l’organisme notifié ? - Qui arbitre entre produit, sécurité, qualité et délai ? - Qui peut dire non ? Dans un projet critique, l’absence de ownership est une faille d’architecture. ### 6\. Stabiliser avant d’optimiser - Réduire le périmètre non essentiel ; - figer les changements risqués ; - documenter avant de migrer ; - corriger les risques critiques ; - éviter les grands refactorings non nécessaires ; - garder une trajectoire de migration réaliste ; - distinguer les dettes bloquantes des dettes acceptables temporairement. La perfection technique n’est pas une stratégie de survie. La maîtrise, oui. ### 7\. Documenter les décisions Chaque décision structurante devrait laisser une trace : - contexte ; - options envisagées ; - décision retenue ; - justification ; - risques acceptés ; - impacts sécurité ; - impacts exploitation ; - impacts certification ; - plan de suivi. Une architecture sans mémoire devient une succession d’accidents polis, pour pallier ce problème, je conseille de tenir à minima à jours les documents suivants : - dossier d'architecture (DA ou DAT pour l'architecture technique), livrable central qui décrit la vision globale de la solution, les grands choix techniques, les contraintes, les composants, les flux, les dépendances et les impacts ; - l'architecture decision records, qui documente une décision d’architecture précise ; - threat model, pour identifier les scénarios d’attaque possibles ; - schémas C4, schéma de plusieurs niveau rendant une architecture lisible (pouvant être intégré au DA) ; - cartographie des flux, pour comprendre les échanges. --- ## À retenir Obtenir une certification Class IIa dans une startup n’est pas seulement un exercice réglementaire. C’est un révélateur brutal de maturité technique et organisationnelle. Le premier enseignement, c’est qu’un produit qui fonctionne n’est pas forcément un produit certifiable. La production prouve que le système tourne. Elle ne prouve pas qu’il est maîtrisé, documenté, sécurisé, traçable et défendable. Le deuxième enseignement, c’est que la dette technique coûte toujours plus cher lorsqu’elle rencontre une exigence de preuve. Ce qui pouvait sembler acceptable dans une phase de croissance devient un obstacle majeur dès qu’il faut expliquer, auditer et justifier. Le troisième enseignement, c’est que la cybersécurité ne peut pas être ajoutée à la fin comme une couche de vernis. Elle doit structurer l’architecture, l’exploitation, les accès, les pipelines, les flux et la documentation. Le quatrième enseignement, c’est qu’il faut savoir renoncer à la réécriture idéale. Dans un contexte contraint, la bonne décision n’est pas toujours la plus élégante techniquement. C’est celle qui réduit le risque, restaure la maîtrise et permet à l’équipe d’avancer sans mentir sur l’état réel du système. Le dernier enseignement est plus dur : une startup peut brûler un budget considérable sans construire les fondations nécessaires à son propre avenir. Ce n’est pas toujours par incompétence. Souvent, c’est par absence de cadre, par urgence permanente, par arbitrages différés, par décisions locales non reliées à une vision globale. Mais au moment de la certification, l’addition arrive. Et elle ne se règle pas avec des slides. Elle se règle avec de l’architecture, de la preuve, de la sécurité, de la documentation, des choix assumés, et une équipe capable de regarder le système tel qu’il est réellement. Pas tel qu’on aurait aimé qu’il soit.