J’ai perdu un marché public sur une case non cochée — les 7 étapes d’homologation que j’applique depuis

La consultation était gagnée sur le fond. Prix cohérent, référence sectorielle solide, équipe disponible. Nous avons été écartés sur une ligne du règlement de consultation que personne, de notre côté, n’avait pris au sérieux : le candidat devait décrire la démarche d’homologation du téléservice qu’il allait exploiter.

Nous avions répondu en trois phrases et une mention de nos sauvegardes. Le concurrent retenu avait joint une stratégie d’homologation datée, un extrait d’analyse de risque et un plan de traitement. Il ne vendait pas une meilleure solution. Il vendait un dossier que l’acheteur pouvait instruire sans travail supplémentaire.

Depuis, nous traitons l’homologation comme un livrable commercial, préparé avant l’appel d’offres et non pendant. Voici la procédure en sept étapes que nous appliquons, et ce qu’elle coûte réellement.

Ce qu’est une homologation, et ce qu’elle n’est pas

L’homologation de sécurité est une décision, pas un audit. C’est l’acte par lequel une autorité désignée — l’autorité d’homologation — atteste formellement, sur la base d’un dossier et d’une analyse de risques, qu’un système d’information est protégé conformément aux objectifs fixés, et qu’elle accepte les risques résiduels en connaissance de cause.

Cette formulation contient tout le malentendu habituel. L’homologation ne certifie pas qu’un système est sûr. Elle acte qu’un responsable identifié a compris ce qui restait exposé et a décidé de mettre le service en production quand même. Ce n’est pas un label : c’est un transfert de responsabilité documenté.

Trois conséquences pratiques en découlent, et elles changent la façon de préparer le dossier. Un système imparfait peut être homologué si les risques résiduels sont explicités et acceptés. Un système techniquement irréprochable sera refusé si personne n’est capable de dire ce qui reste exposé. Et le document qui compte le plus n’est pas le rapport de pentest, c’est la liste des risques résiduels assortie d’un plan d’action daté.

Qui homologue quoi : la clarification qui fait gagner des semaines

Si vous êtes une PME qui répond à un marché public, vous n’êtes pas l’autorité d’homologation. Vous ne signez rien. L’autorité est côté donneur d’ordre : elle est en général le responsable de l’entité qui met le service à disposition du public, et elle engage sa responsabilité en signant.

Votre rôle est d’alimenter le dossier, et il représente en pratique la grande majorité de son contenu, puisque vous seul connaissez l’architecture, les flux et les mesures effectivement implémentées. Cette asymétrie explique pourquoi les projets dérapent : l’acheteur attend un dossier, le fournisseur attend une instruction, et les deux découvrent le malentendu six semaines avant la mise en service.

La procédure en 7 étapes

Étape 1 — Délimiter le périmètre par écrit, avant toute analyse

Écrivez ce qui est dans le système homologué et, surtout, ce qui n’y est pas. Un téléservice s’appuie presque toujours sur des briques que vous n’exploitez pas : hébergeur, service d’envoi d’e-mails, fournisseur d’identité, passerelle de paiement. Chacune doit être nommée et qualifiée : dans le périmètre, hors périmètre mais sous contrat, ou hors périmètre et hors contrôle.

Cette étape prend une demi-journée et détermine tout le reste. Un périmètre flou produit une analyse de risque impossible à conclure, parce qu’aucun scénario ne peut être fermé. Si vous disposez déjà d’une cartographie de votre système d’information, vous avez la matière ; sinon, commencez par là.

Étape 2 — Qualifier les enjeux pour calibrer la profondeur

Toutes les homologations ne se valent pas, et l’erreur coûteuse consiste à traiter un formulaire de contact comme un système de gestion de données de santé. Le guide de l’ANSSI est explicite sur ce point : la profondeur de la démarche doit être proportionnée aux enjeux.

Posez trois questions et écrivez les réponses. Combien de personnes sont concernées par les données traitées ? Quelle est la nature de ces données — administratives, financières, sensibles au sens du RGPD ? Que se passe-t-il concrètement si le service est indisponible une journée, ou si les données fuitent ? Le niveau d’exigence de tout le dossier découle de ces trois réponses, et les écrire vous évite de sur-investir sur un service à faible enjeu.

Étape 3 — Nommer les acteurs, y compris ceux d’en face

Identifiez par leur nom l’autorité d’homologation, la personne qui pilote le dossier côté acheteur, l’expert technique qui posera les questions difficiles, et votre propre référent. Faites-le dès la phase de candidature, pas au moment du dépôt.

C’est l’étape la plus rentable et la moins technique. Dans la moitié des dossiers que nous reprenons, le retard ne vient pas d’une faiblesse de sécurité mais de l’absence d’interlocuteur désigné côté donneur d’ordre : le dossier attend une décision que personne ne se sent autorisé à prendre.

Étape 4 — Conduire l’analyse de risque, en EBIOS RM si possible

C’est le cœur du dossier et l’étape que les PME sous-traitent le plus volontiers. La méthode EBIOS Risk Manager, promue par l’ANSSI, est celle que les acheteurs publics reconnaissent sans discussion ; une autre méthode reste recevable si elle est décrite et cohérente, mais elle vous obligera à justifier ce choix.

Le livrable attendu tient en trois éléments : les événements redoutés, formulés en langage métier et non technique ; les scénarios qui y mènent, avec une évaluation de leur vraisemblance et de leur gravité ; et les objectifs de sécurité qui en découlent. Comptez deux à quatre semaines pour un téléservice de taille moyenne, dont la moitié en ateliers avec les équipes métier.

Étape 5 — Mesurer l’écart, et le mesurer vraiment

Entre les objectifs de sécurité fixés à l’étape précédente et l’état réel du système, il existe un écart. L’étape consiste à le documenter avec des preuves plutôt qu’avec des déclarations : rapport de test d’intrusion, extraits de configuration, matrice d’habilitations, politique de sauvegarde et résultat du dernier test de restauration.

C’est ici que le test d’intrusion trouve sa place — et seulement ici. Beaucoup d’entreprises commandent un pentest en premier, par réflexe, avant même de savoir quels objectifs de sécurité il est censé vérifier. Le rapport arrive alors sans grille de lecture, et sa valeur dans le dossier est proche de zéro.

Étape 6 — Traiter, puis assumer ce qui reste

Corrigez ce qui peut l’être dans le calendrier du projet. Pour le reste, produisez la pièce décisive : la liste des risques résiduels, chacun avec une justification, une mesure compensatoire lorsqu’elle existe, et une date de traitement.

Contre-intuitivement, un dossier qui déclare cinq risques résiduels documentés inspire davantage confiance qu’un dossier qui n’en déclare aucun. Le second signale, aux yeux d’un instructeur expérimenté, que l’analyse a été menée superficiellement. L’autorité d’homologation ne cherche pas un système parfait : elle cherche à savoir ce qu’elle signe.

Étape 7 — Faire vivre la décision après la signature

Une homologation a une durée de validité, fixée dans la décision elle-même et fréquemment comprise entre un et trois ans. Elle devient surtout caduque en pratique dès que le périmètre change de façon significative : nouveau module, changement d’hébergeur, nouvelle catégorie de données, nouveau sous-traitant.

Inscrivez donc deux déclencheurs dans votre processus interne. Une revue à date fixe, calée sur l’échéance de la décision. Et une revue événementielle, déclenchée par toute mise en production qui modifie le périmètre décrit à l’étape 1. C’est la seule manière d’éviter la situation classique : une homologation valide sur le papier, portant sur un système qui n’existe plus.

Les trois erreurs qui coûtent le plus cher

• Commencer par le pentest. Sans objectifs de sécurité définis, le rapport ne prouve rien d’instruisable et il faudra souvent le refaire après l’analyse de risque. C’est le doublon le plus fréquent et le plus évitable.
• Confondre conformité RGPD et homologation. Une analyse d’impact relative à la protection des données traite du risque pour les personnes concernées ; l’homologation traite du risque pour le système et pour la mission. Les deux se nourrissent mutuellement, aucune ne remplace l’autre.
• Attendre la demande du client. Une stratégie d’homologation préparée à froid se réutilise d’un marché à l’autre en changeant le périmètre. Rédigée sous contrainte de calendrier, elle mobilise l’équipe technique au pire moment du projet.

Ce que nous avons compris en perdant cette consultation tient en une phrase : l’acheteur public n’évalue pas votre niveau de sécurité, qu’il n’a pas les moyens de vérifier. Il évalue votre capacité à lui fournir un dossier qu’il pourra faire signer. C’est une compétence documentaire autant que technique, et elle se prépare avant d’en avoir besoin.