Analyse de l’existant : 5 angles d’audit avant cible

L’analyse de l’existant sert à comprendre précisément la situation actuelle avant de définir une solution cible. Elle se place en amont d’un projet, avant l’analyse des besoins et l’analyse des écarts, pour éviter de construire une transformation sur des suppositions. Son objectif n’est pas de tout documenter, mais de distinguer ce qui fonctionne, ce qui bloque, ce qui contraint et ce qui doit être conservé ou amélioré.

Table des matières

Ce que recouvre vraiment l’analyse de l’existant

L’analyse de l’existant est une phase d’audit structurée qui porte sur les processus, les outils, les données, les acteurs et l’environnement dans lequel l’organisation évolue. Elle peut concerner un système d’information, une application métier, une organisation interne, une chaîne de traitement, un parcours client ou un dispositif opérationnel plus large.

Elle ne se limite pas à décrire “ce qui est là”. Une bonne analyse explique comment l’existant fonctionne, pourquoi il fonctionne ainsi, quelles dépendances il crée et quelles limites il impose au projet. Elle doit permettre à une équipe projet, à un business analyst, à un chef de projet ou à une direction métier de partager une même lecture de départ.

Elle est généralement menée avant l’initialisation du changement ou dans les toutes premières étapes du cadrage. À ce stade, les décisions structurantes ne sont pas encore prises : choix d’un outil, refonte de processus, évolution d’architecture, externalisation, automatisation ou mise en conformité. L’analyse sert donc de socle factuel avant de formuler des besoins, puis de mesurer les écarts entre la situation actuelle et la cible attendue.

Les 5 angles à auditer pour obtenir une vision fiable

Pour être utile, l’analyse doit couvrir plusieurs dimensions complémentaires. Se concentrer uniquement sur les fonctionnalités d’un outil ou sur les irritants exprimés par les utilisateurs donne une vision incomplète. Les 5 angles ci-dessous permettent de structurer la collecte sans se perdre dans un inventaire interminable.

Le contexte stratégique, réglementaire et organisationnel

Commencez par identifier l’environnement dans lequel s’inscrit le projet. Existe-t-il un plan stratégique, une contrainte réglementaire, une obligation légale, une politique groupe, un objectif de performance ou une échéance déjà fixée ? Ces éléments orientent le périmètre de l’analyse et évitent de proposer une cible irréaliste.

Il faut aussi repérer les limitations internes ou externes : budget, ressources disponibles, contrats en cours, dépendance à un prestataire, dispersion géographique des équipes, sous-traitance, contraintes de sécurité ou niveaux d’approbation. Ces informations ne sont pas accessoires : elles déterminent souvent ce qui pourra réellement changer.

Les processus et flux de travail

L’audit des processus existants consiste à observer les étapes réelles, pas seulement les procédures officielles. Qui déclenche l’action ? Quels documents circulent ? Où les données sont-elles ressaisies ? Quels contrôles sont manuels ? Quels délais ou contournements reviennent souvent ?

Un processus peut être conforme sur le papier et inefficace dans la pratique. L’analyse doit donc repérer les écarts entre le fonctionnement prescrit et le fonctionnement vécu. C’est souvent là que se trouvent les irritants, les doublons, les ruptures de responsabilité et les opportunités d’amélioration les plus concrètes.

Les acteurs, rôles et interactions système-acteurs

Une analyse de l’existant pertinente cartographie les parties prenantes : utilisateurs finaux, approbateurs, contributeurs, consultés, équipes support, administrateurs, responsables métier, responsables SI et, selon les cas, partenaires externes. Pour chaque acteur, il faut comprendre son rôle, ses décisions, ses contraintes et son niveau d’exposition au changement.

Les interactions système-acteurs méritent une attention particulière. Un même outil peut être utilisé différemment selon les équipes, les sites ou les niveaux d’habilitation. Documenter ces usages évite de concevoir une cible trop théorique, déconnectée des pratiques quotidiennes.

L’architecture actuelle et les interdépendances

L’analyse des solutions informatiques existantes couvre les applications, interfaces, bases de données, flux entrants et sortants, traitements automatisés, fichiers intermédiaires et dépendances avec des systèmes externes. L’objectif n’est pas de produire une architecture exhaustive si le projet ne le nécessite pas, mais d’identifier les éléments qui influencent le changement.

Une dépendance technique mal repérée peut bloquer une migration, fausser une estimation ou créer un risque sur les données. Il est donc utile de préciser les systèmes maîtres, les points d’intégration, les responsabilités de maintenance, les contraintes de reprise de données et les zones de fragilité connues.

Les besoins métier couverts et les fonctionnalités existantes

L’analyse doit distinguer les besoins métier principaux, sans lesquels l’organisation ne peut fonctionner, des besoins secondaires qui contribuent à la performance ou au confort d’usage. Cette distinction aide à prioriser ce qui doit absolument être maintenu dans la solution cible.

Pour les fonctionnalités existantes, évitez le catalogue brut. Reliez chaque fonctionnalité à un usage, à un acteur et à un niveau de criticité. Une fonctionnalité peu visible peut être essentielle pour une équipe support, tandis qu’une fonctionnalité très demandée peut n’être qu’un contournement d’un processus mal conçu.

Les questions à poser pour collecter les bonnes informations

La qualité de l’analyse dépend beaucoup des questions posées aux parties prenantes. Elles doivent faire émerger les faits, les irritants, les dépendances et les priorités, sans orienter trop vite vers une solution.

Thème	Questions utiles	Ce qu’il faut obtenir
Contexte	Quels objectifs stratégiques ou réglementaires encadrent le projet ?	Contraintes, priorités, périmètre non négociable
Processus	Quelles étapes sont manuelles, répétitives ou sources d’erreurs ?	Irritants, doublons, ruptures de flux
Acteurs	Qui réalise, valide, consulte ou est informé ?	Rôles, responsabilités, circuits de décision
Système d’information	Quels outils échangent des données avec la solution analysée ?	Interfaces, dépendances, risques techniques
Besoins métier	Quelles activités seraient impossibles sans l’existant actuel ?	Fonctions critiques et priorités de continuité

Un bon réflexe consiste à utiliser une jauge de criticité pour chaque information collectée : indispensable, important, utile, secondaire. Ce simple classement change la discussion. Au lieu d’accumuler des remarques au même niveau, l’équipe distingue ce qui menace la continuité d’activité, ce qui réduit la performance, ce qui relève du confort utilisateur et ce qui peut attendre. Cette lecture graduée aide aussi à arbitrer lorsque les parties prenantes défendent des priorités contradictoires.

Les entretiens doivent être complétés par l’examen de documents, de procédures, de tickets support, de rapports d’activité, de schémas d’architecture ou de données d’usage lorsque ces éléments existent. La validation par les parties prenantes est ensuite essentielle : elle permet de corriger les malentendus, de confirmer les observations et d’éviter qu’un rapport soit contesté au moment de décider.

Les livrables attendus d’une analyse de l’existant

Les livrables doivent être adaptés à la taille du projet. Une analyse légère peut tenir dans quelques pages structurées ; une transformation plus large nécessitera des cartographies, matrices et annexes techniques. Dans tous les cas, les livrables doivent rester lisibles et exploitables.

Le rapport d’analyse

Le rapport d’analyse présente le périmètre, la méthode de collecte, les acteurs rencontrés, les processus observés, les solutions informatiques existantes, les contraintes, les besoins actuellement couverts et les limites identifiées. Il doit séparer les faits observés des interprétations ou recommandations.

Une structure efficace consiste à partir du contexte, puis à décrire les processus, les acteurs, l’architecture, les besoins métier et les points de friction. Chaque constat important doit être relié à une preuve : entretien, document, observation terrain, schéma, donnée d’usage ou retour récurrent des utilisateurs.

La cartographie et les matrices de synthèse

Selon le projet, vous pouvez produire une cartographie des processus, une matrice acteurs-rôles, une vue des flux applicatifs, une liste des fonctionnalités existantes ou une matrice des contraintes. Ces supports sont précieux pour aligner les métiers et la DSI, car ils rendent visibles des dépendances souvent implicites.

Le livrable n’a pas besoin d’être complexe pour être utile. Un tableau clair indiquant processus, acteur responsable, outil utilisé, donnée manipulée, irritant constaté et criticité peut déjà fournir une base solide pour l’analyse des besoins.

Les recommandations et premiers axes d’amélioration

L’analyse de l’existant débouche naturellement sur des recommandations. Elles peuvent concerner la simplification d’un processus, la suppression d’une ressaisie, la clarification d’un rôle, la sécurisation d’un flux, la mise à jour d’une donnée de référence ou la modernisation d’une solution.

Ces recommandations ne remplacent pas la conception de la cible. Elles servent à préparer l’analyse des écarts et à orienter le plan d’amélioration. Il est donc préférable de formuler des recommandations hiérarchisées, avec un niveau d’impact, une difficulté estimée et les dépendances à traiter.

Comment rédiger une analyse exploitable jusqu’à la décision

La rédaction doit permettre à un décideur comme à un opérationnel de comprendre rapidement la situation. Évitez deux écueils fréquents : le document trop descriptif, qui accumule les informations sans conclusion, et le document trop orienté solution, qui saute l’étape du diagnostic.

Une trame simple peut suivre cet ordre : périmètre étudié, méthode de collecte, contexte et contraintes, processus actuels, acteurs et responsabilités, architecture et interdépendances, besoins couverts, limites et risques, synthèse des forces et faiblesses, recommandations. Cette progression donne une logique claire, de l’observation vers la décision.

Il est également utile de signaler les zones d’incertitude. Une donnée non confirmée, un processus variable selon les sites ou une dépendance technique à investiguer doivent apparaître explicitement. La transparence renforce la crédibilité de l’analyse et évite de transformer une hypothèse en vérité projet.

Enfin, gardez l’analyse vivante. Dans certains projets, les informations évoluent rapidement : organisation modifiée, outil remplacé, nouvelle contrainte réglementaire, arbitrage stratégique. Une mise à jour continue des données, même légère, permet de conserver un diagnostic fiable jusqu’à la phase de décision et de planification des initiatives d’amélioration.