Mise à jour d’un logiciel de gestion : ce que coûte le report

En août 2026, une fédération nationale de sécurité civile a annoncé publiquement avoir subi une violation de données personnelles survenue cinq mois plus tôt, en mars. État civil, coordonnées téléphoniques et photos de profil de bénévoles — dont des mineurs — figuraient dans les fichiers exfiltrés, selon le compte rendu de franceinfo. L’épisode s’inscrit dans une série d’attaques visant des structures comparables sur la même période, notamment plusieurs fédérations sportives.

La mise à jour d’un logiciel de gestion n’est pas une opération de confort fonctionnel : c’est une mesure de sécurité. Chaque version corrige des défauts dont la description devient publique le jour de la publication du correctif. Rester sur une version ancienne revient donc à conserver des failles dont la carte est connue de tous, sauf de l’organisation qui les héberge.

À retenir

• Un correctif publié documente la faille qu’il répare : la version d’avant devient plus exposée après la publication, pas avant.
• Association ou entreprise, l’organisation utilisatrice reste responsable de traitement au sens du RGPD, même quand un prestataire édite le logiciel.
• Le retard se cumule : chaque palier sauté ajoute ses propres correctifs à la dette.
• Une montée de version se prépare (sauvegarde, préproduction, fenêtre, RETEX), elle ne s’improvise pas un vendredi soir.
• Les données de bénévoles mineurs appellent une vigilance renforcée, la CNIL les considère comme un public à protéger particulièrement.

Que révèle vraiment une version ancienne ?

Une version ancienne n’est pas « une version qui a moins de fonctions » : c’est une version dont les défauts connus n’ont pas été réparés, alors que leur description circule. C’est le point que les organisations sous-estiment le plus souvent.

Le cycle est toujours le même. Un défaut est découvert, l’éditeur écrit un correctif, il le publie et le documente. À partir de cette publication, n’importe qui peut lire la note de version, comparer le code d’avant et d’après, et en déduire exactement ce que la version précédente laissait passer. Le correctif protège ceux qui l’installent et renseigne ceux qui ne l’installent pas. Une organisation qui reporte la mise à jour ne reste pas au niveau de risque de la veille : elle descend d’un cran à chaque publication.

Cette mécanique explique pourquoi le silence n’est pas un indicateur. « Nous n’avons jamais eu de problème sur cette version » ne dit rien de son exposition ; cela dit seulement que personne n’a encore essayé, ou que personne ne s’en est aperçu. Dans l’affaire citée plus haut, cinq mois séparent l’intrusion de mars de l’annonce d’août. Pendant ces cinq mois, l’organisation fonctionnait normalement.

L’enjeu n’est théorique pour personne, et il ne concerne pas que le monde associatif. Une association de sécurité civile, une entreprise de sécurité privée, une société de transport sanitaire, une agence d’intérim, un centre de formation ou une entreprise du BTP tiennent le même type de base : adresses, numéros de téléphone personnels, photographies, dates de naissance, qualifications, parfois des informations d’aptitude médicale — et, du côté associatif, les coordonnées de personnes mineures engagées comme jeunes bénévoles. Ces données servent directement à joindre quelqu’un chez lui, la nuit, pour une astreinte ou une urgence : c’est leur raison d’être, et c’est aussi ce qui les rend précieuses pour un tiers malveillant.

Qui est responsable quand le logiciel n’est pas à jour ?

Le RGPD distingue le responsable de traitement, qui décide des finalités et des moyens, du sous-traitant qui exécute pour son compte. L’organisation qui gère un fichier de bénévoles ou de salariés — association, entreprise ou collectivité — est responsable de traitement : cette qualité ne se délègue pas au prestataire logiciel.

L’article 32 du règlement impose au responsable de traitement de mettre en œuvre les « mesures techniques et organisationnelles appropriées » au regard du risque, en tenant compte de « l’état des connaissances » et des coûts. Maintenir un logiciel dans une version pour laquelle des correctifs de sécurité existent et n’ont pas été appliqués est difficile à présenter comme une mesure appropriée au sens de ce texte.

La répartition des rôles gagne à être écrite noir sur blanc, avant l’incident :

Acteur	Ce qu’il maîtrise	Ce dont il répond
Votre organisation (responsable de traitement)	décision de mettre à jour, calendrier, budget, comptes et droits, hébergement si l’installation est sur son infrastructure	licéité du traitement, sécurité globale, notification à la CNIL, information des personnes
Éditeur du logiciel	qualité du code, publication des correctifs, documentation des montées de version	mise à disposition des correctifs, information sur les versions supportées
Hébergeur ou infogérant	système d’exploitation, sauvegardes, filtrage réseau, journalisation	disponibilité, cloisonnement, restitution des sauvegardes
Délégué à la protection des données	pilotage de la conformité, registre, analyse d’impact	conseil documenté et alerte du responsable

Un éditeur ne peut pas mettre à jour à la place d’un client qui refuse la fenêtre d’intervention, surtout lorsque l’installation tourne sur l’infrastructure du client. C’est la différence de fond entre une installation locale et une offre infogérée : dans le second cas, la montée de version fait partie du service et ne dépend plus d’un arbitrage interne. Notre article sur le cloud pour une association multi-sites détaille les conséquences pratiques de ce choix d’architecture.

Le contrat de sous-traitance prévu à l’article 28 est le bon endroit pour figer ces obligations réciproques. Si le vôtre est ancien ou verbal, l’accord de confidentialité sur la protection des données donne les clauses à reprendre.

Comment mesurer le retard accumulé par votre installation ?

Le bon indicateur n’est pas l’âge de la version en mois, mais le nombre de paliers de version publiés depuis celle que vous exécutez. Chaque palier apporte ses correctifs ; sauter un palier ne les annule pas, il les reporte.

Posez trois questions à votre prestataire, et exigez une réponse écrite :

1. Quelle version exacte tourne en production, et à quelle date a-t-elle été publiée ?
2. Combien de versions ont été publiées depuis, et lesquelles contenaient des correctifs de sécurité ?
3. Cette version est-elle encore supportée, c’est-à-dire recevra-t-elle un correctif si un défaut est découvert demain ?

La troisième question est la plus importante et la moins posée. Une version hors support ne bénéficie d’aucun correctif : le défaut découvert la semaine prochaine y restera, définitivement. Aucune configuration, aucun pare-feu, aucune politique de mot de passe ne compense durablement cette situation.

Le retard produit ensuite un effet de seuil que les équipes techniques connaissent bien :

Retard	Ce que cela change concrètement
Un palier	montée de version courte, écart fonctionnel faible, formation des utilisateurs inutile
Deux à trois paliers	migration de données à contrôler, quelques écrans déplacés, une préproduction devient utile
Quatre paliers et plus	migrations en cascade, dépendances système à relever, reprise de paramétrage, formation à prévoir
Version hors support	plus aucun correctif ; la montée devient un projet, et l’exposition court pendant ce temps

C’est ce mécanisme qui transforme un report raisonnable en blocage durable : plus on attend, plus la mise à jour coûte, et plus le coût devient un argument pour attendre encore. La sortie de cette boucle passe par une décision datée — conseil d’administration, comité de direction ou direction générale selon la structure — et non par une bonne intention.

Comment planifier une montée de version sans arrêter l’activité ?

Une montée de version maîtrisée tient en cinq étapes : sauvegarde vérifiée, répétition sur une copie, fenêtre annoncée, bascule, et contrôle de reprise. L’étape que l’on saute le plus souvent est la première — et c’est la seule qui soit irremplaçable.

• Sauvegarde complète et testée. Une sauvegarde dont la restauration n’a jamais été essayée n’est pas une sauvegarde. Restaurez-la sur un serveur de test et connectez-vous réellement à la copie obtenue.
• Répétition sur une copie de production. Rejouez la montée de version sur un jeu de données réel et anonymisé si nécessaire. C’est là que se découvrent les paramétrages exotiques, les intégrations oubliées et les documents mal encodés.
• Fenêtre annoncée aux utilisateurs. Choisissez un créneau hors dispositif opérationnel, informez les responsables d’antenne, et prévoyez une procédure dégradée pour les astreintes pendant l’indisponibilité.
• Bascule et contrôle immédiat. Vérifiez d’abord les fonctions vitales : connexion, planning du jour, alerte, envoi de messages, export. Un défaut sur ces chemins impose le retour arrière sans discussion.
• Contrôle à J+7. Les défauts d’usage se révèlent à la première semaine complète, pas à la première heure. Ouvrez un canal de remontée dédié et traitez-le.

Pour les organisations qui ne disposent pas d’un service informatique, la question du calendrier se pose autrement : l’infogérance déplace la charge vers l’éditeur et supprime l’arbitrage interne qui, année après année, finit par produire le retard. Les associations agréées de sécurité civile trouveront dans notre guide sur la gestion d’une association agréée de sécurité civile le reste du cadre organisationnel.

Enfin, la mise à jour applicative n’est qu’une des couches. Le système d’exploitation, la base de données, le serveur web et les bibliothèques tierces suivent leur propre calendrier. Le portail cybermalveillance.gouv.fr rappelle les bonnes pratiques de mise à jour pour l’ensemble de ces couches, et l’ANSSI publie les recommandations applicables aux structures qui traitent des données sensibles.

Questions fréquentes

Une mise à jour peut-elle casser notre paramétrage ?

Elle peut modifier des écrans, déplacer des options ou faire évoluer un comportement. C’est précisément l’objet de la répétition sur une copie de production : elle transforme une mauvaise surprise en tâche planifiée. Le risque réel d’une montée de version répétée est très inférieur au risque d’exposition d’une version obsolète.

Notre logiciel n’est pas exposé sur Internet, sommes-nous concernés ?

Oui. Une base accessible uniquement depuis le réseau interne reste atteignable par un poste compromis, un accès distant, un prestataire ou un compte volé. Le cloisonnement réseau réduit la surface d’attaque, il ne remplace pas les correctifs.

Que faire si notre budget ne permet pas la montée de version cette année ?

Documentez la décision. Inscrivez au registre des traitements le retard constaté, l’analyse de risque associée et la date prévue de résorption, et faites-la valider par votre instance dirigeante — bureau, conseil d’administration ou direction. Une décision tracée et assumée n’est pas équivalente à un oubli, ni du point de vue de la CNIL, ni de celui de votre assureur.

Faut-il prévenir nos équipes que le logiciel n’est pas à jour ?

L’obligation d’information porte sur le traitement de leurs données, pas sur l’état de vos correctifs. En revanche, dès lors qu’une violation est constatée, l’information des personnes concernées devient une obligation autonome, décrite par la CNIL sur les violations de données personnelles.

Combien de temps faut-il pour rattraper plusieurs versions de retard ?

Cela dépend du nombre de paliers, du volume de données et du degré de personnalisation. Comptez la préparation en semaines et la bascule en heures. L’essentiel est de fixer une date : sans date, le rattrapage ne commence jamais.

Pour situer votre installation, notre frise des versions d’eBrigade et des moyens de protection montre, palier par palier, ce que chaque version met à disposition — et ce dont une version ancienne ne dispose tout simplement pas.

Le fichier de vos bénévoles ou de vos salariés est un actif opérationnel — il sert à joindre des gens en urgence — et un fichier de données personnelles sensible par nature. Le tenir à jour suppose de tenir à jour l’outil qui l’héberge. eBrigade publie ses versions, documente ses paliers de migration et propose une offre infogérée dans laquelle la montée de version est assurée par l’éditeur, sans arbitrage annuel à l’intérieur de l’association.