Audit de l’existant : 5 angles à vérifier

L’analyse de l’existant sert à comprendre la situation actuelle avant de définir une solution cible. Elle intervient en amont d’un projet, avant l’analyse détaillée des besoins et l’analyse des écarts. Son objectif n’est pas de produire un inventaire pour le principe, mais de repérer ce qui fonctionne, ce qui bloque, ce qui limite le changement et ce qui doit être conservé.

Dans un projet métier, digital, organisationnel ou SI, cette phase évite de construire une stratégie à l’aveugle. Elle donne une base factuelle aux décisions : processus en place, outils utilisés, acteurs impliqués, flux de données, limites réglementaires, irritants opérationnels et dépendances techniques.

Table des matières

Définir le périmètre avant de collecter l’information

Une analyse de l’existant pertinente commence par une question simple : de quel existant parle-t-on ? Sans périmètre clair, l’audit devient vite une accumulation d’observations hétérogènes. Le périmètre peut porter sur un processus métier, une application, un service, une organisation, un parcours utilisateur ou une chaîne complète d’interactions entre plusieurs systèmes.

Ce que l’analyse doit couvrir

Le socle minimal comprend généralement l’environnement de l’organisation, les objectifs stratégiques auxquels le projet doit se conformer, les contraintes légales ou réglementaires, les processus existants, les solutions informatiques utilisées et les acteurs concernés. Il faut aussi identifier les limitations connues : budget, délais, compétences internes, dépendances fournisseurs, sous-traitance, sites géographiques dispersés ou contraintes de sécurité.

L’enjeu est de relier chaque élément observé à son impact sur le projet. Une contrainte réglementaire peut imposer une règle de conservation des données. Une architecture vieillissante peut limiter l’intégration avec une nouvelle solution. Un processus manuel peut expliquer des délais, mais aussi révéler une souplesse métier à ne pas perdre. Cette lecture évite de traiter tous les constats avec le même niveau d’urgence.

Le bon moment dans le projet

L’analyse de l’existant se réalise avant l’initialisation concrète du changement, lorsque les hypothèses sont encore ouvertes. Elle précède la formalisation fine des besoins, car elle permet de distinguer un besoin réel d’une demande de solution déjà formulée. Par exemple, une équipe peut demander un nouvel outil de reporting alors que le problème vient d’une mauvaise qualité des données ou d’un circuit de validation trop long.

Cette phase peut ensuite être mise à jour. Les informations collectées au démarrage doivent être validées avec les parties prenantes, puis ajustées si de nouveaux éléments apparaissent. Une analyse figée trop tôt perd rapidement sa valeur, surtout dans les projets où plusieurs métiers, systèmes ou prestataires interviennent.

Auditer les processus, les acteurs et les interactions

L’audit ne consiste pas seulement à demander “comment ça marche aujourd’hui ?”. Il doit faire apparaître les flux de travail réels, les responsabilités, les contournements, les points de friction et les dépendances invisibles. C’est souvent dans l’écart entre la procédure officielle et la pratique quotidienne que se trouvent les informations les plus utiles.

Cartographier les rôles et responsabilités

Il est utile de distinguer les acteurs qui réalisent, ceux qui approuvent, ceux qui sont consultés et ceux qui doivent être informés. Cette lecture clarifie les interactions système-acteurs et évite d’oublier des profils clés : utilisateurs finaux, managers, administrateurs, équipes support, responsables conformité, partenaires externes ou sous-traitants.

Les entretiens doivent couvrir les tâches effectuées, les décisions prises, les validations nécessaires, les irritants rencontrés et les informations échangées. Une bonne pratique consiste à demander des exemples concrets : un dossier récent, une demande traitée, une anomalie fréquente, un cas bloquant. Ces exemples rendent l’analyse plus fiable qu’une description théorique.

Observer les flux plutôt que les organigrammes

L’organigramme indique qui dépend de qui, mais il ne montre pas toujours comment le travail circule. L’analyse des flux de travail doit suivre les entrées, les traitements, les sorties, les délais, les points de contrôle et les reprises manuelles. Elle doit également repérer les doubles saisies, les fichiers intermédiaires, les validations informelles et les ruptures entre services.

Pour comprendre un blocage, il faut regarder le fonctionnement réel, pas seulement la procédure affichée. Les règles implicites, les dépendances entre équipes, les champs obligatoires dans une application, les droits d’accès, les délais de réponse et les habitudes de contournement ont souvent plus d’effet sur le résultat qu’un organigramme bien dessiné. C’est ce niveau de détail qui permet ensuite de proposer une solution compatible avec l’organisation.

Examiner l’architecture actuelle et les solutions en place

Dans un projet impliquant le système d’information, l’analyse de l’existant doit documenter l’architecture actuelle. Il ne s’agit pas de produire un schéma technique complexe pour tous les publics, mais de comprendre les applications utilisées, les données manipulées, les interfaces, les dépendances externes et les limites connues.

Les informations technologiques à collecter

Les informations utiles portent sur les outils en production, leurs principales fonctionnalités, leurs utilisateurs, leur criticité, leur niveau d’intégration et les flux de données entrants ou sortants. Il faut aussi identifier les systèmes externes connectés, les formats d’échange, les traitements automatiques, les exports manuels et les éventuelles redondances.

Cette collecte permet de repérer les risques avant de concevoir la solution cible. Une application peut couvrir un besoin métier critique tout en reposant sur un mode de maintenance fragile. Un fichier partagé peut sembler secondaire alors qu’il sert de pivot opérationnel entre deux équipes. Une interface avec un système externe peut conditionner tout le calendrier du projet.

Fonctionnalités, usages réels et limites

La solution existante doit être décrite à travers ses fonctionnalités, mais aussi à travers ses usages réels. Certaines fonctionnalités disponibles ne sont jamais utilisées ; d’autres sont détournées pour répondre à un besoin non prévu. L’analyse doit donc croiser la documentation officielle avec les observations terrain et les retours utilisateurs.

Il est pertinent de classer les besoins métier couverts en trois niveaux : les besoins critiques sans lesquels l’organisation ne peut pas fonctionner, les besoins secondaires ayant un impact fort sur la performance, puis les besoins non critiques mais utiles au confort de travail. Cette hiérarchisation prépare directement l’analyse des écarts entre l’existant et la cible.

Transformer les constats en livrables exploitables

Une analyse de l’existant n’a de valeur que si elle aboutit à des livrables clairs, validables et réutilisables. Le rapport ne doit pas être une simple retranscription d’entretiens. Il doit structurer les constats, mettre en évidence les forces et faiblesses, signaler les risques et préparer les décisions.

Les livrables attendus

Selon la taille du projet, les livrables peuvent inclure une cartographie des processus, une description des acteurs et responsabilités, un inventaire des solutions informatiques existantes, une synthèse des contraintes, une analyse des flux de données, une liste des irritants, une matrice des risques et un rapport d’analyse avec recommandations.

Thème audité	Questions à poser	Livrable associé
Contexte	Quels objectifs stratégiques, contraintes légales ou réglementaires encadrent le projet ?	Synthèse de cadrage
Acteurs	Qui réalise, approuve, consulte ou utilise les informations ?	Cartographie des parties prenantes
Processus	Quelles étapes, validations, délais et contournements existent aujourd’hui ?	Cartographie des flux de travail
Système d’information	Quels outils, interfaces, données et interdépendances soutiennent l’activité ?	Vue d’architecture actuelle
Besoins métier	Quels besoins critiques et secondaires sont déjà couverts ou mal couverts ?	Préparation de l’analyse des écarts

Validation et fiabilisation des constats

La validation par les parties prenantes est indispensable. Elle permet de corriger les incompréhensions, d’arbitrer les divergences de perception et de confirmer la criticité des problèmes. Un utilisateur opérationnel, un responsable métier et une équipe technique ne décrivent pas toujours le même existant, car chacun voit une partie différente du système.

La restitution doit donc distinguer les faits observés, les interprétations et les recommandations. Cette séparation renforce la crédibilité de l’analyse et facilite les arbitrages. Elle évite aussi de transformer trop tôt un irritant en solution imposée.

Passer de l’existant à l’analyse des écarts

La dernière étape consiste à relier l’état actuel à la solution cible. L’analyse de l’existant prépare l’analyse des besoins, puis l’analyse des écarts : ce qui est déjà couvert, ce qui manque, ce qui doit évoluer, ce qui doit être supprimé et ce qui doit être sécurisé pendant la transition.

Les recommandations doivent être priorisées selon la criticité métier, l’impact utilisateur, la faisabilité technique, les contraintes réglementaires et les dépendances projet. Toutes les faiblesses détectées ne méritent pas une action immédiate. Certaines relèvent d’une amélioration continue, d’autres conditionnent le succès du changement.

À conserver : pratiques efficaces, données fiables, contrôles utiles, fonctionnalités critiques.
À améliorer : étapes lentes, ressaisies, validations redondantes, reporting incomplet.
À remplacer : outils obsolètes, processus non maîtrisés, dépendances trop risquées.
À surveiller : contraintes externes, interconnexions sensibles, adoption par les utilisateurs.

Une analyse de l’existant réussie ne conclut pas seulement sur ce qui doit changer. Elle donne une lecture structurée de la réalité actuelle et crée un pont fiable vers les besoins, les écarts, les recommandations et le plan d’amélioration. C’est cette continuité qui transforme l’audit en véritable outil de décision.