Découverte de Shadow IT : Trouver des applications non documentées

Toute organisation sait qu'elle est confrontée à l'informatique parallèle. Un chiffre illustre parfaitement le problème : la plupart des organisations utilisent plus de 1 000 applications cloud, et le service informatique n'en contrôle généralement que moins de 10 %. Les grandes entreprises utilisent en moyenne 473 applications SaaS ; le service informatique n'en gère directement qu'une infime partie. 80 % des employés utilisent des applications non autorisées pour travailler. Ces chiffres sont constants d'une étude à l'autre, car la dynamique qu'ils reflètent est la même : les employés et les unités opérationnelles adoptent des outils qui résolvent des problèmes immédiats plus rapidement que les processus de gouvernance informatique ne peuvent les évaluer et les approuver.

En 2026, le débat sur l'informatique parallèle (shadow IT) était dominé par les outils de détection SaaS qui analysaient les journaux DNS, les jetons d'authentification unique OAuth, les notes de frais et le trafic réseau afin de repérer les applications cloud utilisées sans autorisation par les employés. Ces outils résolvent le problème au niveau SaaS, et ce de manière satisfaisante. Cependant, ils ne résolvent pas l'autre aspect de l'informatique parallèle, à savoir les applications sur mesure, les programmes batch non documentés, les pipelines de données informels et les utilitaires fantômes présents dans les portefeuilles d'applications d'entreprise et jamais répertoriés dans un système de gestion des actifs, un journal des modifications ou un inventaire informatique. Il ne s'agit pas d'applications cloud déployées par les employés, mais de programmes de production exécutés sur des mainframes et des systèmes de moyenne puissance, assurant des fonctions critiques dont les organisations propriétaires ne peuvent justifier l'utilisation.

Ces deux problèmes requièrent des approches de détection différentes. Le problème du shadow IT SaaS exige une visibilité réseau et une intégration des identités. Le problème du shadow IT au niveau du code exige l'analyse des artefacts logiciels (code source, bibliothèques de chargement, flux de tâches JCL) afin d'identifier les programmes existants et leur fonction. Ce guide aborde les deux, en se concentrant plus particulièrement sur la seconde catégorie, jusqu'ici négligée.

Les deux problèmes liés à l'informatique parallèle

L'informatique parallèle (Shadow IT) est généralement définie comme l'ensemble des technologies utilisées au sein d'une organisation sans l'approbation ni la connaissance explicite du service informatique. Cette définition recouvre deux phénomènes fondamentalement différents qui requièrent des approches de détection et des réponses de gouvernance distinctes.

Les outils SaaS et cloud « shadow » désignent les applications et services utilisés par les employés ou les unités opérationnelles sans passer par un service informatique officiel. Par exemple : une équipe marketing utilisant un outil de rédaction IA non autorisé ; une équipe financière partageant des feuilles de calcul via un compte Dropbox personnel ; un développeur utilisant un assistant de codage IA non autorisé qui envoie du code source propriétaire à une API externe. Ces applications existent en dehors de l’infrastructure de l’organisation et sont détectables par des signaux externes : requêtes DNS, autorisations OAuth, lignes de notes de frais, empreintes du trafic réseau.

Les logiciels fantômes , sujet de cet article, désignent les programmes et processus par lots développés sur mesure au sein de l'infrastructure interne de l'organisation, sans documentation, inventaire ni gouvernance adéquates. Par exemple : un programme COBOL écrit en 1994 par un développeur du service financier pour gérer un cas particulier de calcul fiscal ; un programme RPG créé par un analyste métier pour générer des fichiers EDI pour un partenaire commercial spécifique ; un traitement JCL exécuté chaque fin de mois et produisant un rapport réglementaire essentiel à l'équipe de conformité, développé par un prestataire ayant quitté l'organisation en 2009 ; et un utilitaire Java écrit « temporairement » lors d'un projet d'intégration de systèmes en 2018, devenu une dépendance permanente sans décision préalable.

Ces programmes ne sont pas visibles dans les journaux DNS car ils s'exécutent sur une infrastructure interne. Ils n'apparaissent pas dans les enregistrements d'autorisation OAuth car ils sont antérieurs à OAuth. Ils ne figurent pas dans l'inventaire officiel des applications car ils n'ont jamais été soumis à un examen formel de la gouvernance informatique. Leur détection n'est possible qu'en examinant l'infrastructure elle-même, les bibliothèques de chargement, les dépôts de code source, les planificateurs de tâches et les journaux d'exécution qui révèlent quels logiciels sont réellement exécutés dans l'environnement.

Au-delà de l'exhaustivité de l'inventaire, l'importance de ce point réside dans le fait que 74 % des organisations ont subi des incidents de sécurité liés à des actifs inconnus ou non gérés. Les applications fantômes représentent cette catégorie d'actifs inconnus, indétectables aussi bien par les outils de découverte réseau que par les plateformes de visibilité SaaS.

Pourquoi les logiciels d'application fantômes s'accumulent-ils ?

Comprendre pourquoi les applications personnalisées non documentées prolifèrent dans les environnements d'entreprise explique pourquoi les processus de gouvernance standard ne parviennent pas à les empêcher et pourquoi une découverte rétrospective est nécessaire.

L'impératif d'une solution immédiate. Les unités opérationnelles sont confrontées à des problèmes spécifiques qui requièrent des solutions spécifiques. L'application approuvée ne gère pas les cas particuliers. La file d'attente des demandes informatiques est saturée. Un développeur, parfois au sein du service informatique, parfois intégré à une équipe métier, conçoit une solution fonctionnelle. La solution est exécutée, résout le problème et s'intègre au flux de travail opérationnel. Le processus de gouvernance formel n'est jamais mis en œuvre car le problème est déjà résolu.

Le schéma du temporaire devenu permanent. La forme la plus insidieuse de logiciels d'application fantôme commence par une solution explicitement temporaire. « Juste le temps que le système principal soit prêt. » « Un contournement rapide pour le problème de format de données. » « Temporaire, en attendant que le fournisseur corrige son API. » Les solutions temporaires deviennent permanentes lorsque les dépendances qui s'accumulent autour d'elles ne sont jamais supprimées. Le correctif de calcul de date COBOL écrit pour la résolution du problème de l'an 2 est encore utilisé vingt-cinq ans plus tard, car aucun développeur ultérieur n'a su pourquoi il existait ni s'il était possible de le supprimer sans risque. Le script de normalisation de base de données « temporaire » a été intégré au traitement par lots nocturne, car l'application cible n'a jamais été réellement compilée.

L'échec du transfert de connaissances. Les applications fantômes, développées par certains individus, disparaissent de la documentation de l'organisation lorsque ces individus la quittent. Le programme continue de fonctionner, intégré aux processus de production qui en dépendent, mais aucune documentation n'existe, aucun responsable n'est désigné et personne ne connaît son fonctionnement avec suffisamment de précision pour le modifier en toute sécurité. Il devient un fantôme dans l'environnement de production : visible par ses effets, invisible par sa gouvernance.

Le pipeline de données parallèle. L'intégration de données est un terrain particulièrement fertile pour les logiciels personnalisés non documentés. Lorsque la couche ETL officielle ne prend pas en charge une transformation nécessaire, ou lorsqu'un processus métier exige que les données circulent entre les systèmes plus rapidement que ne le permet le processus d'intégration officiel, les développeurs créent des programmes de déplacement de données non officiels. Un script Python interroge la base de données de production et écrit les résultats sur un lecteur partagé, où un processus en aval les récupère. Un programme COBOL lit les données de la base de données DB2 du mainframe et les écrit dans un fichier plat qu'une application cloud ingère. Ces pipelines de données non officiels franchissent les frontières des systèmes, traitent des données potentiellement sensibles et fonctionnent entièrement en dehors du cadre de gouvernance de l'intégration.

Les quatre catégories de logiciels d'application fantôme

Catégorie 1 : Applications personnalisées des unités commerciales

Des programmes conçus par des développeurs intégrés aux unités opérationnelles (finance, achats, opérations, conformité) et qui résolvent des problèmes spécifiques à un domaine. Ces programmes se caractérisent généralement par :

• Leurs noms sont informels (TAXCALC, VENDREPT, ADJBATCH) et ne suivent pas les conventions d'appellation d'entreprise.
• Les répertoires ou bibliothèques sont gérés par l'unité commerciale plutôt que par le service informatique.
• Aucune entrée dans la base de données de gestion de la configuration (CMDB)
• Aucun responsable technique n'a été désigné dans le système de gestion des services informatiques.
• Absence de documentation formelle, de couverture de tests et d'historique de contrôle des modifications

Leur criticité est souvent sous-estimée car l'unité opérationnelle connaît le fonctionnement du programme et le considère comme « le sien ». La DSI, ignorant son existence, est incapable d'en évaluer la criticité. L'absence du programme dans l'inventaire des applications de la DSI implique son exclusion du plan de continuité d'activité (PCA), du plan de reprise après sinistre, des évaluations de sécurité et du périmètre du programme de modernisation.

Catégorie 2 : Programmes fantômes

Il s'agit de programmes exécutés en production, mais dont l'origine, la finalité et le propriétaire sont inconnus de l'organisation. Ils existent dans les bibliothèques de chargement et les référentiels de code source, sont appelés par d'autres programmes ou exécutés par des tâches JCL, et produisent des résultats dont dépendent les processus en aval. Cependant, la mémoire organisationnelle relative à leur raison d'être et à leurs responsables s'est perdue.

Les programmes fantômes sont particulièrement dangereux du point de vue de la sécurité et de la conformité, car ils ne peuvent être évalués au regard des normes actuelles, ne peuvent être inclus dans les programmes d'analyse des vulnérabilités qui exigent l'attribution de la propriété de l'application, et ne peuvent être évalués en matière de conformité réglementaire, car personne ne sait à quelles données ils accèdent ni quelle fonction commerciale ils servent.

Catégorie 3 : Pipelines de données fantômes

Programmes non officiels permettant de transférer des données entre des systèmes situés en dehors de l'architecture d'intégration officielle. Ces programmes vont des alternatives ETL sophistiquées aux simples scripts de transfert de fichiers.

python

# Typical shadow data pipeline -- production database to shared storage
# Written 2021, "temporary until the API is ready"
# Still running daily as of 2026, owner left organization 2022

import pyodbc, shutil
from pathlib import Path

conn = pyodbc.connect('DSN=PROD_BILLING;UID=svcacct;PWD=...')  # hardcoded creds
cursor = conn.execute("SELECT * FROM BILLING_RECORDS WHERE STATUS = 'PENDING'")
rows = cursor.fetchall()

# Write to shared drive that Finance picks up
output_path = Path(r'\\FILESERVER01\Finance\billing_export.csv')
with output_path.open('w') as f:
    for row in rows:
        f.write(','.join(str(v) for v in row) + '\n')

shutil.copy(output_path, Path(r'\\ARCHIVE\billing\') / f"billing_{date.today()}.csv")

Ce programme, représentatif d'un schéma courant dans les environnements d'entreprise, utilise des identifiants de base de données de production codés en dur, écrit des données de facturation sensibles sur un emplacement réseau partagé sans chiffrement et fonctionne sans surveillance depuis des années après le départ de son auteur. Il est invisible pour les outils de détection SaaS car il s'exécute sur une infrastructure interne. Il est également invisible lors de l'analyse du trafic réseau car il utilise des protocoles de base de données standard ne produisant aucune signature identifiable. Il n'est visible que dans le code source.

Catégorie 4 : Tâches par lots non documentées

Flux de travaux JCL et programmes planifiés exécutés sur l'infrastructure de production mais absents de la documentation officielle de planification des travaux. Ces éléments s'accumulent par :

• Tâches soumises en dehors du planificateur de tâches standard par soumission directe
• Programmes appelés dynamiquement depuis d'autres programmes (et donc non visibles indépendamment dans les inventaires du planificateur)
• Les tâches qui s'exécutent peu fréquemment, en fin de mois, en fin d'année, ou seulement lorsque des conditions commerciales spécifiques se présentent, et qui n'ont jamais été prises en compte lors des audits d'inventaire de routine.
• Emplois hérités de systèmes précédents qui ont été « migrés » mais jamais officiellement mis hors service

Les traitements par lots non documentés deviennent des points de défaillance critiques lorsque :

• Une fenêtre de maintenance a un impact sur le système sur lequel ils fonctionnent, et personne ne pense à avertir l'unité commerciale qui dépend de leur production.
• Une évaluation de sécurité est effectuée et ces tâches s'exécutent en tant que comptes de service non surveillés avec des privilèges élevés.
• Un programme de modernisation définit le périmètre de la migration en fonction du calendrier des tâches documenté et arrive dans l'environnement cible sans certaines fonctionnalités critiques de traitement par lots.

Méthodes de découverte par catégorie de logiciels fantômes

Les méthodes de détection appropriées pour l'informatique parallèle des SaaS sont en grande partie inapplicables aux logiciels d'application parallèles. Les méthodes requises sont les suivantes :

Analyse de la bibliothèque de chargement. Chaque programme compilé et déployé sur un système mainframe ou midrange est présent dans une bibliothèque de chargement, le référentiel des exécutables. La comparaison des programmes de cette bibliothèque avec ceux de l'inventaire officiel des applications révèle un écart : tout module de chargement présent dans la bibliothèque mais absent de l'inventaire est un programme fantôme. Cette analyse ne nécessite aucun code source ; elle porte sur les exécutables compilés et leurs métadonnées.

Exploration des référentiels de code source. Les référentiels de code source (PDS de code source COBOL, dépôts Git, bibliothèques de code source RPG) contiennent tous les programmes jamais écrits, y compris ceux développés et déployés de manière informelle, et jamais enregistrés dans les systèmes de gouvernance informatique. L'exploration complète du référentiel de code source par rapport à la CMDB révèle les programmes présents dans le code source mais non enregistrés dans la gouvernance.

Réconciliation JCL et ordonnanceur. Chaque flux de travaux JCL exécuté en production, qu'il soit soumis via l'ordonnanceur officiel, manuellement ou lancé par un autre travail, laisse une trace dans le journal d'exécution (JESLOG, SYSLOG). La comparaison des programmes présents dans les journaux d'exécution de production avec ceux de l'inventaire officiel permet d'identifier les programmes exécutés en production sans contrôle de gouvernance.

Analyse dynamique des appels. Les programmes qui appellent d'autres programmes de manière dynamique, le nom du programme appelé étant déterminé à l'exécution et non à la compilation, créent des dépendances invisibles pour l'analyse statique de l'ordonnanceur. L'analyse dynamique des appels permet de suivre les programmes émettant des instructions CALL avec des noms de programme variables, d'identifier l'ensemble des programmes susceptibles d'être appelés et de signaler les programmes accessibles par répartition dynamique qui pourraient ne pas figurer dans une carte de dépendances statique.

Traçage des flux de données. Les pipelines de données fantômes sont détectables par l'analyse des schémas d'accès au système de fichiers et aux bases de données : quels programmes lisent ou écrivent dans quels ensembles de données, fichiers ou tables de base de données. Un programme qui lit une base de données de production et écrit dans un chemin de fichier situé en dehors de la hiérarchie de gestion des données standard est un candidat potentiel pour un pipeline fantôme.

La dimension de l'IA de l'Ombre

L'extension du problème de l'informatique parallèle en 2026 concerne l'IA parallèle : les employés et les unités opérationnelles utilisent des outils et des agents d'IA sans autorisation informatique. Selon le rapport d'IBM sur le coût d'une violation de données en 2026, 43 % des incidents de sécurité impliquent des employés utilisant l'IA parallèle. Gartner prévoit que d'ici 2030, plus de 40 % des entreprises subiront un incident de sécurité ou de conformité lié à l'IA parallèle non autorisée.

Le risque spécifique lié à l'IA parallèle, et directement pertinent pour l'informatique parallèle au niveau du code, concerne l'intégration de code source propriétaire dans des assistants de programmation IA. Un employé utilisant un assistant de programmation IA non autorisé pour un programme COBOL existant transmet le code source de ce programme à un fournisseur d'IA externe. Ce code source peut contenir des identifiants codés en dur, une logique métier constituant un secret commercial, ou des structures de données dont la divulgation enfreint les règles de résidence des données. La méthode de détection de ce risque spécifique n'est pas l'analyse du trafic réseau, mais la détection des programmes accédés par des outils communiquant avec des API d'IA externes, ce qui requiert une surveillance au niveau applicatif plutôt qu'au niveau réseau.

Le problème de l'IA fantôme et celui des applications fantômes partagent une caractéristique importante : ils sont invisibles aux outils de détection réseau qui dominent le marché de l'informatique fantôme SaaS. Leur détection nécessite soit une surveillance au niveau applicatif, soit une analyse structurelle du code.

Constitution de l'inventaire complet des applications

Le résultat d'un programme de découverte des technologies informatiques fantômes pour les logiciels d'application d'entreprise est un inventaire consolidé qui couvre quatre populations :

Programmes connus et documentés : programmes figurant à la fois dans l’inventaire officiel et dans l’environnement de production. Ces programmes bénéficient d’une gouvernance, de responsables désignés, d’un historique des modifications et de plans de reprise après sinistre.

Programmes connus mais non déployés : programmes figurant dans l’inventaire officiel mais introuvables dans les bibliothèques de chargement ou les journaux d’exécution en production. Ces programmes sont susceptibles d’être mis hors service ; ils ont peut-être été désactivés sans procédure formelle adéquate ou leur liste est peut-être erronée.

Programmes inconnus mais déployés (programmes fantômes) : programmes apparaissant dans les journaux d’exécution en production ou les bibliothèques de chargement, mais non répertoriés dans l’inventaire officiel. Il s’agit du principal constat d’informatique fantôme, nécessitant une attribution de responsabilité immédiate, une évaluation de sécurité et un enregistrement auprès des instances de gouvernance.

Dépendances non documentées : programmes qui n’apparaissent ni dans l’inventaire officiel ni dans les journaux d’exécution de production principaux, mais qui sont découverts par analyse dynamique des appels ou par traçage des flux de données comme étant accessibles depuis les processus de production. Ce sont les programmes fantômes, les plus difficiles à trouver et les plus dangereux à ignorer.

La réconciliation entre ces quatre populations aboutit au plan d'action : recenser les programmes parallèles, évaluer leur niveau de sécurité, en attribuer la propriété et déterminer leur sort, les gouverner et les maintenir, les moderniser ou les mettre hors service.

Comment SMART TS XL Effectue une découverte Shadow IT au niveau du code

SMART TS XLL'approche de [Nom de l'entreprise] en matière de découverte du shadow IT s'attaque aux catégories de code que les outils réseau ne peuvent pas atteindre.

L' analyse statique du code commence par un parcours complet du référentiel source : chaque programme COBOL, module RPG, application PL/I, service Java, script Python et flux de travaux JCL de l'environnement est catalogué avec son emplacement source, son langage, sa taille et un profil de complexité préliminaire. Cet inventaire sert de référence pour la mise à jour de la CMDB et du registre officiel des applications. Les programmes présents dans le référentiel source mais absents de l'inventaire officiel constituent la principale source d'applications fantômes.

La cartographie des dépendances applicatives résout le problème des appels dynamiques : en traçant chaque instruction CALL dans chaque programme, y compris les appels dynamiques où le nom du programme est une variable, la cartographie des dépendances identifie les programmes accessibles depuis les processus de production même s'ils n'apparaissent jamais dans les inventaires statiques du planificateur. Un programme fantôme appelé dynamiquement par dix programmes de production apparaît dans la cartographie des dépendances même s'il ne possède aucune définition de tâche JCL indépendante.

La fonctionnalité d'expansion JCL retrace l'intégralité de la chaîne d'exécution de chaque flux de travaux JCL : résolution des références PROC, expansion des paramètres symboliques et construction de la liste complète des programmes invoqués par chaque travail. La comparaison de cette liste avec la documentation officielle du planning des travaux permet d'identifier automatiquement les travaux et programmes exécutés en production sans documentation.

L' analyse d'impact permet de tirer profit des découvertes : pour chaque programme fantôme détecté, recensez tous les processus de production qui en dépendent. Un programme fantôme sans dépendance est un code mort, pouvant être supprimé sans risque. Un programme fantôme avec vingt dépendances en production représente un actif critique non documenté nécessitant une intervention immédiate de la gouvernance. L'étendue de l'impact détermine la priorité de la correction.

La fonction de recherche d'entreprise permet d'interroger l'inventaire complet : elle permet de trouver tous les programmes accédant à un ensemble de données spécifique (candidats potentiels pour les pipelines de données fantômes), tous les programmes écrits après une date précise et ne disposant d'aucune entrée dans la CMDB (applications fantômes récentes), ainsi que tous les programmes écrivant dans des répertoires de fichiers externes situés en dehors de la hiérarchie de gestion des données standard. Cette fonction de recherche facilite à la fois la détection initiale et la surveillance continue, empêchant ainsi la reprise de l'accumulation d'applications fantômes après le nettoyage initial.

Pour les organisations menant des programmes de modernisation de systèmes existants , la détection des applications fantômes est une étape indispensable. Un programme de modernisation qui définit le périmètre de la migration à partir de l'inventaire officiel des applications et découvre les applications fantômes en cours d'exécution est un programme dont le périmètre, le calendrier et le budget étaient inadaptés dès le départ. La détection, qui aurait dû avoir lieu avant la planification, se fait désormais pendant l'exécution, au moment où elle est la plus coûteuse.

La réponse de la gouvernance : non pas bloquer, mais assurer la visibilité

Les organisations qui gèrent efficacement l'informatique parallèle en 2026 ont constaté que l'interdiction générale est inefficace et crée des incitations perverses. Le signalement de l'informatique parallèle échoue dans la plupart des organisations pour une raison simple : les employés s'attendent à être sanctionnés. Lorsqu'un membre de l'équipe financière utilise un outil de suivi des dépenses non autorisé et le signale lui-même, l'équipe de sécurité, en le réprimandant, a conditionné cet employé, ainsi que tous ses interlocuteurs, à se taire la prochaine fois.

Le même principe s'applique aux applications fantômes. Un développeur ayant créé un utilitaire COBOL critique pour l'entreprise et dont dépend cette dernière ne devrait pas être sanctionné pour ne pas avoir suivi un processus de gouvernance qui n'a peut-être pas été clairement communiqué à l'époque. La réponse de la gouvernance face à la découverte d'applications fantômes devrait être la suivante :

Enregistrement, et non suppression. Les programmes fantômes découverts dans le chemin critique des processus métier ne doivent pas être supprimés ; ce sont des applications de production non documentées qui nécessitent une gouvernance. Enregistrez-les, désignez des responsables, évaluez leur niveau de sécurité et appliquez-leur la même rigueur de gouvernance que toute autre application de production.

Amnistie pour auto-divulgation. Un programme de gouvernance qui crée des canaux sécurisés permettant aux unités opérationnelles de divulguer les applications informelles qu'elles ont développées permet de détecter les logiciels non officiels plus rapidement que toute approche technique de découverte. La garantie que la divulgation entraîne un soutien de la gouvernance, une aide à la documentation, un audit de sécurité et un enregistrement officiel, plutôt que des mesures disciplinaires, supprime toute incitation à la dissimulation.

Prévention par les processus. La prolifération des applications parallèles est due à des frictions de gouvernance : le processus officiel de demande de développement de nouvelles applications est plus lent que les besoins métiers. En réduisant ces frictions, grâce à une gouvernance de développement rapide et allégée, un soutien intégré à la gouvernance informatique au sein des unités opérationnelles et une procédure d'approbation simplifiée pour les outils internes à faible risque, on diminue le nombre de nouvelles applications parallèles sans nécessiter d'analyse technique continue.

L'inventaire que vous pensez avoir n'est pas celui que vous avez réellement.

L'écart entre l'inventaire des applications géré par le service informatique et les logiciels réellement exécutés en entreprise est loin d'être négligeable. Dans les grandes organisations où s'accumulent des décennies d'applications, ce décalage peut atteindre près de 30 % du total des programmes. Ces 30 % non documentés comprennent des programmes qui traitent des données sensibles, assurent la conformité réglementaire, sont essentiels aux processus métier critiques et présentent des failles de sécurité que personne n'a jamais examinées, faute de savoir qu'il fallait le faire.

Les outils de détection de shadow IT SaaS permettent de bien appréhender la couche cloud de ce problème. Le shadow IT au niveau du code, c'est-à-dire les programmes personnalisés, les utilitaires fantômes, les pipelines de données informels et les traitements par lots non documentés qui pullulent dans les environnements hérités des entreprises, exige une approche différente : l'analyse structurelle des artefacts logiciels eux-mêmes, plutôt que la simple surveillance du trafic réseau. L'inventaire qui en résulte est souvent surprenant par son exhaustivité. Les organisations qui entreprennent cette démarche constatent régulièrement que ce qu'elles pensaient avoir en production et ce qui est réellement en production sont deux choses sensiblement différentes. Combler cet écart est fondamental pour tout programme de gouvernance, de sécurité, de continuité d'activité et de modernisation qui repose sur une connaissance précise du fonctionnement réel de l'organisation.