Quatre mesures, un chronomètre, et le coût de l’écart
Votre développeur annonce que l’application métier est prête. Lundi, vous allez y charger le fichier clients, les prix négociés et les tournées de la semaine. « Est-elle sécurisée ? » n’appelle aucune réponse vérifiable : personne ne peut le prouver, et vous ne pouvez pas le réfuter.
Quatre choses se mesurent, elles. Restaurez l’application entière dans un environnement séparé et notez la durée. Déclenchez un événement sensible et comptez les minutes avant qu’une personne nommée reçoive l’alerte. Rejouez dix requêtes avec le compte le moins privilégié et lisez les codes de réponse. Listez les dépendances vulnérables, puis triez-les par exploitation constatée plutôt que par score.
Chacune sort un nombre, que vous comparez à un seuil fixé par votre direction et non par un référentiel. Dans le cas construit ci-dessous, une heure ouvrée sans l’application coûte 993 € ; la direction accepte quatre heures d’arrêt, soit 3 972 €. L’exercice de restauration a duré six heures quarante sur une copie : subie un jour ouvré, cette durée vaudrait 6 620 €, dont 2 648 € au-dessus du seuil. « Sécurisé » ne se discute pas.
Ces 2 648 €, eux, se discutent en comité de direction. Et si l’une des quatre mesures ne peut pas être exécutée, notez-le tel quel : vous ne saurez pas davantage la faire le jour de l’incident.
Fil rouge du guide · exemple construit
Trente-quatre utilisateurs, 3 100 clients, une mise en service prévue lundi
Exemple construit : l’entreprise, ses volumes, ses horaires et ses coûts internes sont choisis pour l’exemple et ne viennent d’aucune source ; seuls les montants de prestation sont repris de notre grille publiée. Ce n’est pas un dossier client. Une société de négoce et d’installation de matériel médical, 46 salariés, 12 millions d’euros de chiffre d’affaires. Elle remplace un classeur partagé par une application de prise de commande et de tournées, écrite en huit mois par un développeur indépendant.
Trente-quatre personnes s’en serviront : douze commerciaux, six préparateurs de commandes, neuf chauffeurs-livreurs sur téléphone, quatre à l’administration des ventes, deux au contrôle de gestion et le responsable applicatif. La base porte 3 100 clients professionnels, dont 480 praticiens libéraux — des personnes physiques, donc des données personnelles.
Incident en cours : arrêtez cette revue
Si une compromission, une fuite ou une indisponibilité est en cours ou soupçonnée, appliquez la procédure d’incident et appelez les personnes compétentes. Ces quatre mesures préparent une mise en service ; elles ne remplacent ni un isolement, ni une restauration d’urgence.
Combien vous coûte une heure sans l’application ?
Tout le reste dépend de ce nombre. Sans lui, « sauvegarde quotidienne » et « reprise en quatre heures » sont des mots : rien ne dit ce qu’ils achètent, ni à quel prix.
Deux lignes suffisent, et vous les avez déjà
La première : le temps payé qui ne produit rien. Comptez les personnes réellement bloquées — pas tous les utilisateurs — puis multipliez par leur coût employeur horaire. La seconde : la marge qui ne revient pas. Prenez les opérations que l’application enregistre par jour ouvré, multipliez par leur marge brute moyenne, divisez par la durée d’une journée de travail — huit heures ici, de 9 h à 17 h — et gardez la part que vous ne rattraperez pas le lendemain.
Le cas construit donne ceci. Vingt et une personnes sur trente-quatre sont arrêtées, les treize autres reprennent le carnet papier. À 38 € l’heure chargée, cela fait 798 € l’heure. L’application enregistre 62 commandes par jour ouvré à 84 € de marge brute, soit 5 208 € par jour et 651 € l’heure sur huit heures ; la directrice administrative et financière estime que trois commandes sur dix ne reviennent jamais, soit 195,30 € l’heure. Total : 993,30 € l’heure, arrondi à 993 € : tous les montants de ce guide partent de là et non des centimes.
Ce montant vaut par heure ouvrée. La nuit et le week-end, personne n’est payé à attendre et aucune commande ne se prend : un arrêt de vingt-deux heures un samedi ne coûte pas 21 846 €, mais le temps qu’il consomme le lundi matin. Comptez les heures d’arrêt tombées entre 9 h et 17 h, pas celles de l’horloge.
Les huit hypothèses que nous posons à découvert
Huit quantités de ce guide ne sortent d’aucune source, en plus des volumes et des coûts internes du cas construit, annoncés en section 01. Deux produisent des euros directement : 38 € l’heure chargée pour le temps interne, que votre expert-comptable ou votre contrôleur de gestion calcule à partir du salaire brut et des charges patronales, et 500 € la journée de développement pour les corrections chiffrées plus bas, que votre contrat porte.
Les six autres sont des durées d’effort, et elles coûtent au même titre : six minutes par commande ressaisie, deux jours et demi pour corriger trois routes, une heure à cinq personnes pour l’exercice sur table, une demi-journée pour l’exercice de restauration, deux heures d’attente sur un ticket d’hébergement, une journée pour la première série des quatre mesures contre deux heures ensuite, dont les dix minutes, l’heure et la minute détaillées en questions fréquentes. Remplacez-les par les vôtres, comme les volumes du cas.
Ce montant donne un sens à deux seuils qui, sans lui, restent des sigles. La durée maximale d’interruption admissible — DMIA, ou RTO en anglais — est le temps d’arrêt que votre direction accepte de payer : quatre heures ouvrées ici, donc 3 972 €. La perte de données maximale admissible — PDMA, ou RPO — est la saisie que vous acceptez de perdre : une heure ici. L’hébergeur n’en décide aucun.
Le plafond de l’article 83 ne se calcule pas à l’envers
L’article 32 du règlement général sur la protection des données (RGPD) demande des mesures techniques et organisationnelles « appropriées afin de garantir un niveau de sécurité adapté au risque ». Un manquement relève de l’article 83, paragraphe 4 : jusqu’à 10 millions d’euros ou 2 % du chiffre d’affaires annuel mondial, le montant le plus élevé étant retenu. Sur 12 millions d’euros de chiffre d’affaires, 2 % font 240 000 € : c’est donc le plafond de 10 millions qui s’applique. Un plafond n’est pas une sanction : les paragraphes 1 et 2 du même article veulent des amendes « effectives, proportionnées et dissuasives », modulées cas par cas. L’idée reçue « une PME risque 2 % » est fausse dans les deux sens.
Les quatre mesures, et les quatre sujets qui restent à écrire
Une mesure isolée déplace le problème. Prises une par une, elles laissent passer ce qui fait tomber une application métier : un accès verrouillé sert peu si les secrets se lisent dans le dépôt de code, et un journal que personne ne relève n’a jamais alerté personne. Le schéma ci-dessous récapitule les quatre mesures, le nombre que chacune rend et le seuil qui la tranche.
| La mesure | Ce qu’on lance | Le nombre qu’on lit | Le seuil qui tranche |
|---|---|---|---|
| Restauration | Remonter les 5 objets de l’application dans un environnement séparé, chronomètre en main | Minutes de remise en service, et écart avec le dernier enregistrement restauré | Au-delà des 4 h ouvrées de DMIA acceptées, chaque heure coûte 993 € |
| Alerte | Un événement sensible autorisé, à une heure notée : compte d’administration créé, export massif | Minutes entre l’action et l’alerte, nom de qui l’a reçue, durée de conservation des traces | Aucune alerte reçue par une personne nommée en 15 minutes : il n’y a pas de détection, seulement un journal |
| Compte témoin | 10 requêtes rejouées avec le compte le moins privilégié, identifiants changés | Les 10 codes de réponse renvoyés par le serveur : 200, 403 ou 404 | Une seule réponse 200 est bloquante ; les refus obtenus à côté ne compensent pas |
| Dépendances | npm audit, pip-audit ou osv-scanner sur le dépôt livré | Nombre d’alertes par gravité, et jours écoulés depuis la publication du correctif | L’exploitation constatée passe avant le score de gravité |
Rien là-dedans ne demande d’outil payant ; le seul poste coûteux est l’environnement séparé, sans lequel la première mesure se ferait sur la production. Quatre autres sujets s’écrivent au lieu de s’exécuter : conséquences métier, conduite d’un incident, maintenance, responsabilités.
Une exigence se cite avec sa version et son résultat de test
« Nous suivons OWASP » ne désigne rien de vérifiable. Le référentiel ASVS 5.0.0, publié le 30 mai 2025, se cite exigence par exigence, avec ce qui a été testé et avec quel résultat. Le cadre NIST CSF 2.0 (CSWP 29, 26 février 2024) précise lui-même qu’il n’impose ni ordre, ni liste de contrôles universelle. Aucun des deux ne certifie quoi que ce soit. La façon d’écrire une exigence dont on sait décrire l’échec est détaillée dans le cahier des charges SaaS.
Chaque exécution se consigne sur la même fiche. Neuf lignes, et la neuvième est celle qu’on oublie.
Mesure : Date et heure d’exécution : Environnement (jamais la production) : Qui l’a exécutée : Le nombre lu : Le seuil comparé, et qui l’a fixé : Tenu / non tenu : Ce qui manquait : Date de la prochaine exécution :
Votre sauvegarde restaure-t-elle l’application entière ?
« Nous avons des sauvegardes quotidiennes » répond à côté de la question. Elle porte sur ce qui remonte, dans quel ordre et en combien de temps.
Le protocole, en une demi-journée
- Choisissez un environnement séparé. Jamais la production, jamais un environnement qui partage une base, un stockage ou un compte avec elle.
- Notez l’heure de départ, puis restaurez sans appeler le développeur. S’il faut l’appeler, c’est un résultat : votre reprise dépend de sa disponibilité.
- Remontez les cinq objets. La base de données, les fichiers déposés par les utilisateurs, la configuration, les secrets et les comptes. C’est là que ça casse.
- Rejouez les parcours métier complets retenus dans le plan de recette de l’application, ceux dont l’échec coûte de l’argent. Un écran d’accueil qui s’affiche ne prouve rien.
- Notez trois nombres : la durée totale, l’écart entre la dernière écriture et le dernier enregistrement restauré, et le nombre de parcours qui repassent.
| Ce qu’on remonte | Ce que l’exercice a donné | Ce que ça change |
|---|---|---|
| Base de données | Restaurée en 40 minutes, au point du jour à 2 h | Quinze heures entre la sauvegarde et une panne de 17 h : la journée de saisie entière, 62 commandes |
| Fichiers déposés par les utilisateurs | Absents : 9 300 bons signés vivent dans un stockage non couvert | Deux heures d’attente d’un ticket, puis remontée |
| Configuration et secrets | Non sauvegardés, reconstitués depuis un ancien courriel | Une clé d’envoi d’e-mails reste invalide trois jours |
| Comptes et rôles | Restaurés, mais tous avec le rôle par défaut | Les 9 chauffeurs-livreurs héritent des droits de l’administration des ventes |
| Total mesuré | 6 h 40 au lieu des 4 h acceptées | 2 h 40 de trop, soit 2 648 € si la même durée était subie en heures ouvrées |
L’écart ne vient pas de la base, qui revient en quarante minutes, mais des quatre autres objets que personne n’avait listés : il faut les ajouter à ce que la sauvegarde couvre, puis recommencer.
L’exercice lui-même ne coûte que la demi-journée qu’il mobilise, sur une copie : aucune commande n’est perdue, personne n’est bloqué. Les 2 648 € sont ce que la même durée coûterait le jour d’une panne réelle, entre 9 h et 17 h.
La perte de données se lit à part, et une panne de fin de journée le montre bien. La sauvegarde tourne à 2 h ; une panne à 17 h n’interrompt presque rien, la journée est finie, mais elle efface les quinze heures qui la séparent de la sauvegarde, c’est-à-dire toute la saisie du jour. Soit 62 commandes à ressaisir, six minutes chacune à l’administration des ventes : 372 minutes, donc 6 h 12 pour une personne et 235,60 € de temps chargé, sans compter les bons signés que personne ne peut reconstituer. La direction avait annoncé une perte acceptable d’une heure ; entre une heure et quinze, il ne s’agit plus d’un réglage mais d’un autre contrat d’hébergement.
3-2-1 est un repère, pas une preuve de reprise
La règle des trois copies, sur deux supports dont une hors ligne, figure dans ANSSI-BP-100, version 1.1 du 27 novembre 2025, qui précise que ses recommandations ne sont pas normatives sauf texte contraire et doivent être adaptées. Trois copies d’une sauvegarde incomplète restent incomplètes.
Mémo express
Une réplication n’est pas une sauvegarde
Une suppression, une corruption ou un chiffrement malveillant se réplique en quelques secondes. La réplication réduit l’interruption ; seule une copie isolée et versionnée ramène un état antérieur.
Combien de minutes s’écoulent entre l’action et l’alerte ?
Un journal n’est pas une détection. La différence se mesure en minutes.
Un mardi à 14 h 05, le responsable applicatif crée un compte d’administration de test, exporte les 3 100 fiches clients, puis supprime le compte à 14 h 12. Il note l’heure de chaque geste et ne prévient que le propriétaire de l’application, qui l’a autorisé par écrit : prévenir l’équipe reviendrait à mesurer l’attention d’un collègue.
L’exercice rend trois nombres. L’événement figure-t-il dans un journal, et à quelle heure exactement ? Combien de minutes avant qu’une alerte parvienne à une personne nommée ? Combien de temps ces traces restent-elles consultables ?
Les trois réponses tombent mal
L’export figure bien dans le journal applicatif, horodaté 12 h 05 : le serveur écrit en temps universel coordonné (UTC) pendant que le journal du serveur web écrit en heure de Paris, deux heures plus loin en été ; une conversion ratée fait accuser la mauvaise personne. Aucune alerte n’est partie : la règle existait, elle envoyait un courriel à une boîte générique que personne ne relève. Et les journaux de l’offre d’hébergement souscrite sont conservés sept jours.
Ce troisième nombre est le plus coûteux. L’article 33 du RGPD demande de notifier une violation de données personnelles à l’autorité de contrôle dans les meilleurs délais et, si possible, sous 72 heures après en avoir pris connaissance ; l’article 34 impose d’informer les personnes concernées lorsque le risque pour elles est élevé. La fiche CNIL du 14 mars 2024 recommande en général six mois à un an pour les données de journalisation destinées à sécuriser un traitement de données personnelles, avec des adaptations à justifier. Sept jours est la valeur livrée avec l’offre d’hébergement ; personne ne l’a choisie.
Le seuil : si aucune personne nommée n’a reçu l’alerte dans les quinze minutes, écrivez « pas de détection ». La correction tient en trois réglages : une règle qui écrit dans un canal relevé par une personne nommée, un suppléant qui a les mêmes accès, une horloge synchronisée. L’ANSSI recommande d’ailleurs, dans son guide de journalisation version 2.0 du 28 janvier 2022, de prévoir la journalisation dès les spécifications : ajoutée après coup, elle enregistre ce que le code sait déjà dire, quand l’enquête demandera autre chose.
Journaliser davantage crée aussi un risque
Les traces contiennent vite des identifiants, des messages d’erreur détaillés, des données personnelles ou des secrets. La CNIL demande de ne pas enregistrer les mots de passe ni leurs empreintes. Journalisez ce qu’une enquête utiliserait, bornez qui peut lire, fixez une durée.
Le compte témoin lit ce que l’écran lui cache
L’interface montre à chacun ce qu’il a le droit de voir. Le bouton disparaît de l’écran ; la requête, elle, part quand même et le serveur y répond. Posez-lui donc la question directement.
Le protocole du compte témoin
- Ouvrez deux sessions sur l’environnement restauré à la mesure 1 : un compte à droits complets, ici l’administration des ventes, et le moins privilégié, ici un chauffeur-livreur.
- Dans la session privilégiée, ouvrez dix pages sensibles : une fiche client, un tarif négocié, la liste des commandes du jour, un bon de livraison signé, un export de la base clients, une fiche article avec son prix d’achat, l’historique de commandes d’un client, la tournée du lendemain, la liste des utilisateurs et le journal d’activité.
- Récupérez chaque requête. Outils de développement du navigateur, onglet Réseau, clic droit sur la requête, « Copier comme cURL ».
- Remplacez le jeton par celui du chauffeur-livreur et rejouez les dix requêtes telles quelles, sans repasser par l’interface.
- Lisez les dix codes de réponse. 403 ou 404, le contrôle vit côté serveur. 200, il n’existait que dans l’écran.
Sur le cas construit, trois réponses sur dix reviennent en 200. Un chauffeur-livreur lit la fiche de n’importe lequel des 3 100 clients en changeant un nombre dans l’adresse, prix négociés compris. L’OWASP place ce défaut en tête de son Top 10 des risques d’interface de programmation sous le nom de contrôle d’accès rompu au niveau de l’objet.
Le seuil est binaire : une seule réponse 200 bloque la mise en service, et les sept refus obtenus à côté ne compensent rien. Vérifier côté serveur, sur chacune des trois routes, que l’objet demandé appartient bien au client connecté a été chiffré à deux jours et demi, soit 1 250 € à l’hypothèse de 500 € la journée.
Le prix de l’inaction se compte autrement. Sur les 3 100 clients, 480 sont des praticiens libéraux, donc des personnes physiques : une lecture non autorisée avérée est une violation de données personnelles et, si elle est susceptible d’engendrer un risque pour ces personnes, elle se notifie à l’autorité de contrôle sous 72 heures après en avoir pris connaissance. Cette qualification relève de la sécurité et de la protection des données, en coordination avec vos conseils juridiques.
Un droit sans propriétaire, une alerte sans destinataire
Les mêmes dix requêtes posent une question que l’informatique ne tranche pas : qui décide que le chauffeur-livreur ne doit pas voir les prix ? La directrice administrative et financière tranche ; le développeur applique.
Il faut cinq rôles, qu’une même personne peut cumuler : qui signe la mise en service, qui qualifie les alertes, qui déclenche une restauration et détient les accès pour le faire, qui suit les corrections, qui prévient le délégué à la protection des données (DPD, aussi appelé DPO) et, s’il le faut, un juriste. Chacun a un suppléant, et le suppléant a les accès.
L’exercice sur table — une simulation discutée, sans incident réel — dure une heure et mobilise cinq personnes, soit 190 € de temps chargé au tarif du cas. Une alerte arrive un vendredi à 18 h, la personne principale est en congés : qui décide de couper, qui détient le mot de passe d’administration ? Chaque question sans réponse est un accès à confier à un suppléant avant lundi.
Mémo express
Une mesure provisoire porte un nom et une date de fin
Écrivez ce qu’elle empêche, qui la surveille, quand elle expire et ce qui déclenche son arrêt. Couper l’accès des chauffeurs-livreurs aux tarifs pendant deux semaines est une mesure ; « nous ferons attention » n’en est pas une.
Quelle dépendance faut-il corriger cette semaine ?
La quatrième mesure se relance chaque semaine, et produit trop d’informations. Le tri compte davantage que l’analyse.
Sur le dépôt livré, lancez la commande de votre technologie : npm audit pour du JavaScript, pip-audit pour du Python, osv-scanner pour un dépôt mixte. Chacune sort les paquets vulnérables, leur gravité et la version qui corrige. Sur le cas construit : 1 043 paquets installés pour 68 dépendances directes, et 31 alertes — une critique, cinq hautes, quatorze moyennes, onze basses.
Le tri commence par ce qu’on écarte. Les quatorze moyennes et les onze basses rejoignent le lot du mois, où elles partent en une montée de version groupée. Restent les six alertes critiques ou hautes, que trois questions ramènent à une.
| La question posée | Ce qu’elle écarte | Ce qui reste |
|---|---|---|
| Le code vulnérable part-il en production ? | 2 des 6 ne servent qu’à construire le projet ; l’option --omit=dev de npm audit les écarte d’office | 4 |
| L’application appelle-t-elle la fonction concernée ? | 1 alerte porte sur une fonction que le code n’appelle jamais | 3 |
| La faille figure-t-elle au catalogue des vulnérabilités dont l’exploitation est constatée ? | 2 des 3 restantes n’y figurent pas et rejoignent le lot du mois | 1 |
Reste une alerte sur trente et une qui justifie de déranger le développeur cette semaine. Le nombre qui décrit vraiment votre maintenance est ailleurs : le délai entre la publication du correctif et son installation chez vous. Sur le cas construit, la version corrigée est publiée depuis le 14 janvier ; au 26 août 2026, cela fait 224 jours. Inscrivez ce délai au contrat de maintenance, avec celui que vous acceptez.
Sous le mot « score », deux échelles circulent. Le CVSS, dans sa version 4.0, mesure la gravité potentielle sur dix : 9,0 à 10,0 critique, 7,0 à 8,9 élevée, 4,0 à 6,9 moyenne, 0,1 à 3,9 faible. Le score EPSS, publié par le même organisme, estime la probabilité qu’une faille soit exploitée dans les trente jours à venir. Une faille critique que personne n’exploite passe après une moyenne activement utilisée, et le catalogue public des vulnérabilités exploitées tranche gratuitement.
Les quatre sujets que rien ne mesure
Restent les conséquences métier, la conduite d’un incident, la maintenance après la mise en service et les responsabilités. L’outil ci-dessous les remonte dans l’ordre du plus urgent, garde les inconnues visibles et ne calcule aucun score.
Revue avant mise en service · outil local
Quel point devez-vous établir maintenant ?
Choisissez uniquement des états génériques. Ne saisissez ni nom, détail d’incident, information métier, secret ou donnée personnelle : aucune réponse ne quitte la page ni n’est enregistrée durablement par cet outil.
Prochaine étape prudente
Qualifiez d’abord le contexte de l’application
L’impact métier, la présence de données personnelles, l’exposition Internet et l’existence d’un incident changent les contrôles et les personnes à mobiliser.
Points à reprendre
- • Impact métier
- • Données personnelles
- • Exposition Internet
- • Incident actif ou soupçonné
Action : Faites répondre le propriétaire métier, le responsable applicatif et, selon le cas, le délégué à la protection des données (DPD ou DPO), le responsable de la sécurité des systèmes d’information (RSSI) ou un autre spécialiste. Une inconnue reste visible.
Aucun score n’est calculé. Le résultat dépend uniquement de vos choix et ne remplace ni une analyse de risques, ni un audit, ni un test d’intrusion encadré, ni une décision de mise en service.
Remplissez-le une fois avec la directrice administrative et financière, une fois avec le développeur : un désaccord entre les deux vaut mieux qu’un accord de façade.
Que décider quand une mesure dit non ?
Une mesure qui échoue n’interdit pas la mise en service. Elle déplace la décision vers quelqu’un qui a le droit de la prendre, et elle lui donne un montant à comparer.
| La décision | Quand elle se défend | Ce qu’elle oblige à écrire |
|---|---|---|
| Mettre en service | Les quatre mesures passent, et les écarts restants sont chiffrés puis acceptés par la direction | Les risques conservés, leur montant, la date de la prochaine série |
| Corriger, puis remesurer | La correction se paie une fois, l’écart se paie à chaque incident : 1 250 € pour les trois routes qui répondent 200 | Qui corrige, sous quel délai, et la date de la nouvelle exécution |
| Réduire ce qu’on ouvre | L’organisation ne tient pas les rôles : pas de suppléant, pas de journaux conservés | Ce que l’application ne contiendra pas encore : données personnelles, accès depuis Internet, montants |
| Pilote sur données fictives | L’apprentissage reste utile et l’activité ne dépend pas de l’application | La date de fin du pilote, sinon il devient la production par inertie |
| Reporter | Une mesure n’a pas pu être exécutée du tout : pas d’environnement séparé, pas d’accès aux journaux | L’action précise qui rendra la mesure possible, et qui la mène |
Sur les cinq issues, trois mettent quelque chose en service, et c’est voulu. Reporter est la plus rare : un écart mesuré a une correction et un prix, quand une mesure jamais exécutée n’a ni l’un ni l’autre. Borner la première version coûte d’ailleurs moins cher que repousser la date — le guide quoi inclure dans un MVP sert à cela.
Et dans six mois ?
Ces quatre nombres périment, chacun à son rythme. Vérifiez au passage ce que vous récupérez si vous changez d’équipe : une sauvegarde exportable hors de la plateforme, les journaux, la liste des comptes, les secrets et le code source. Ces clauses s’écrivent avant de signer et se testent une fois, en récupérant réellement une copie. Un droit de récupération jamais exercé reste une hypothèse.
Aucune de ces quatre mesures ne demande de prestation extérieure : un environnement séparé, une règle d’alerte, un compte de test et une ligne de commande suffisent. Si la restauration passe sous votre DMIA, si l’alerte arrive à une personne nommée en moins de quinze minutes, si les dix rejeux sont refusés et si la seule alerte retenue au tri est corrigée, vous n’avez besoin d’aucun audit. Nos repères publics, relevés sur notre page tarifs le 30 août 2026, commencent à 2 000 € HT pour un audit flash, 5 000 € HT pour un cadrage sécurité et RGPD et 8 000 € HT pour un audit technique en version Express, 18 000 € HT en version Standard. Ce sont des repères indicatifs ; le devis signé fixe le prix ferme.
Ce qui rate sur le cas construit, et ce que ça coûte
Ces trois incidents reprennent le même cas construit et des mécanismes documentés par la CNIL, l’ANSSI et l’OWASP — ce ne sont pas des dossiers clients. Ils suivent les huit hypothèses de la section 02 et comptent l’arrêt en heures ouvrées.
La base revient, les bons de livraison non : 2 648 € au-dessus du seuil
Un mardi à 9 h 20, l’hébergement perd le disque de la base. La restauration démarre à 9 h 40, la base revient en quarante minutes. Les 9 300 bons de livraison signés, eux, vivent dans un stockage que la sauvegarde ne couvrait pas : ticket, deux heures d’attente, puis trois heures quarante de remontée et de vérification des parcours. Service rétabli à 16 h, six heures quarante après l’arrêt contre quatre acceptées, et entièrement dans la journée de travail : à 993 € l’heure ouvrée, 6 620 €, dont 2 648 € au-dessus du seuil. Personne n’a été attaqué : la sauvegarde était incomplète, et nul ne l’avait vérifié.
Un export de 3 100 fiches, vu 41 jours plus tard
Un compte ouvert pour un développeur extérieur n’est jamais révoqué. Six semaines plus tard, il exporte les 3 100 fiches clients. Aucune alerte ne part : la règle envoyait un courriel à une boîte générique. Le geste est découvert 41 jours après, en relisant des journaux conservés sept jours, où il ne reste rien. Il faut alors décider, sous 72 heures, s’il y a lieu de notifier un incident dont on ne sait décrire ni l’étendue, ni lesquels des 480 praticiens libéraux sont concernés. La difficulté n’est pas l’amende : c’est de devoir écrire « nous ne savons pas ».
Trois réponses 200 sur dix : 1 250 € de correction
Un commercial change d’entreprise et emporte une capture des tarifs négociés de 3 100 clients. Il lui a suffi de modifier un nombre dans l’adresse depuis son téléphone : l’application répondait 200. Corriger les trois routes vaut 1 250 €, exactement ce que cela aurait coûté avant la mise en service.
Si l’application repose sur une plateforme du marché plutôt que sur du code à vous, le guide Power Apps ou application sur mesure montre ce que l’abonnement couvre. Vous pouvez aussi décrire le projet en indiquant simplement lesquelles des quatre mesures n’ont pas pu être exécutées.
Terminez par une date, pas par un badge
Écrivez l’action qui manque, la personne qui la mène et le jour où le point sera repris. Si la sortie de cette revue est un badge ou le mot « conforme », rien n’a été documenté.
Transparence. Hagnéré Code vend des audits techniques et un accompagnement sécurité et RGPD, et perçoit des honoraires si vous nous les confiez. Les quatre mesures se font sans nous. Les huit hypothèses de coût et de durée listées en section 02 sont annoncées comme telles : aucune n’a été relevée chez un client. Nos prix publics ont été relevés le 30 août 2026 et sont à revérifier tous les douze mois. Aucune de ces mesures ne rend une application sûre, et seul un devis signé engage.