Cas réel anonymisé : 8 constatations issues d'un audit informatique mené auprès d'un groupe comptant plusieurs filiales au Mexique, allant de l'absence de maintenance de l'ERP e depuis 2015 à des sauvegardes jamais testées.
Il s'agit d'un cas réel tiré de l'un de nos audits informatiques au Mexique, rendu anonyme : aucun nom d'entreprise, aucun nom de personne, aucune donnée permettant d'identifier le client. Seules subsistent les constatations techniques — car elles correspondent exactement au type de risque qui se répète dans les groupes d'entreprises comptant plusieurs filiales, et non à une anecdote isolée.
Le groupe audité opérait avec sept sociétés sœurs au sein d'une même holding, toutes gérées par un système de gestion unique développé sur mesure il y a plusieurs années. Voici les conclusions de l'audit.
L'ERP e interne reposait sur une technologie pour laquelle le fabricant lui-même avait cessé d'assurer le support le 13 janvier 2015. Dix ans plus tard, ce système continuait d'assurer le traitement de la comptabilité, de la paie, des crédits et de la facturation de toutes les filiales du groupe. Aucun correctif de sécurité, aucune mise à jour officielle depuis lors — seulement une maintenance interne improvisée.
Il n'existait ni service qualité ni véritable environnement de test. C'était le développeur lui-même qui testait la modification qu'il avait écrite, et la validation finale se faisait par essais et erreurs avec l'utilisateur final, alors que le système était déjà en production. Il n'y avait ni fenêtres de maintenance programmées ni validations systématiques — il s'agissait simplement de vérifier que « le code fonctionnait » après l'avoir modifié.
L'équipe informatique adhérait à la philosophie selon laquelle « le code parle de lui-même » — c'est-à-dire qu'il n'y avait pratiquement pas de commentaires. Il n'existait ni catalogue de variables ni administrateur de bases de données (DBA). La connaissance du système reposait presque exclusivement dans l'esprit d'une seule personne.
Le groupe disposait d'un processus documenté pour demander des modifications : format, validation, tests, mise en œuvre. Dans la pratique, les utilisateurs demandaient les modifications directement en invoquant l'urgence et le coordinateur informatique déterminait la priorité au cas par cas, sans suivre la procédure officielle. Résultat : des modifications en production sans aucune traçabilité quant à leur demandeur, leur motif ni la personne qui les a validées.
Lorsqu'on a posé des questions sur les politiques internes en matière de sécurité et d'utilisation des technologies de l'information, la réponse a été qu'on ne savait pas avec certitude si elles existaient — elles n'ont été mentionnées dans aucun des entretiens. Pour une entité du groupe soumise à la surveillance d'autorités de régulation financières externes, il s'agit d'une lacune aussi importante sur le plan de la conformité que sur le plan technique.
Des sauvegardes quotidiennes étaient effectuées — sur disque physique, dans le cloud et sur un serveur centralisé — mais l'équipe informatique elle-même ignorait quelle application était utilisée pour les générer et si le processus s'exécutait réellement comme décrit. Le délai estimé de reprise après sinistre (DRP) était donné de mémoire — « environ 40 minutes, peut-être une heure » — sans que personne n’ait chronométré une véritable reprise. Même le serveur de secours hors site, mentionné dans le plan de sauvegarde, n’a pas pu être vérifié dans la pratique.
Plusieurs filiales partageaient physiquement le même site et, en cas de panne, il était prévu d'emprunter du matériel à une autre société du groupe afin d'assurer la continuité des opérations. Il s'agit d'une solution ingénieuse pour assurer la continuité à court terme, mais cela signifie également qu'aucune filiale ne disposait d'une frontière de sécurité claire par rapport aux autres: une panne ou une faille au sein d'une société du groupe pouvait exposer les autres.
Dans plusieurs filiales, le coordinateur des systèmes était à la fois responsable de la gestion de projets, développeur principal et support technique de première ligne — et il apportait parfois également son aide à d’autres entreprises du groupe. Il n’y avait aucune redondance des compétences : si cette personne n’était pas disponible, il n’y avait personne d’autre capable de résoudre une panne.
Chaque constat a été classé dans une matrice des risques en fonction de sa gravité — modéré, important ou catastrophique — afin que le groupe puisse établir des priorités et déterminer les points à traiter en premier lieu, plutôt que d’essayer de tout résoudre en même temps. Les points n° 1 (système sans support) et n° 6 (continuité non vérifiée) figuraient en tête de la liste des priorités immédiates.
Aucun des éléments de cette liste n’est inhabituel. On les retrouve, sous différentes formes, dans la plupart des 15 problèmes typiques que nous avons recensés lors d'audits menés dans des filiales: des systèmes hérités dont le propriétaire n'est pas clairement identifié, une continuité des activités qui existe en théorie mais qui n'a jamais été testée, et une concentration excessive de connaissances critiques entre les mains d'une seule personne. C'est exactement ce qu'un audit informatique est censé mettre en lumière avant qu'un incident ne le fasse de manière brutale.
30 minutes avec l'un de nos directeurs. Pas de présentation commerciale — on va droit au but.