L’analyse de l’existant sert à comprendre la situation actuelle avant de définir une solution cible, de lancer un changement ou de rédiger des besoins. Elle permet d’auditer les processus, les outils, les acteurs, les contraintes et les écarts déjà visibles, pour éviter de construire un projet sur des suppositions.
Dans un cadre professionnel, cette étape intervient en amont, avant le démarrage du changement ou au début du cadrage. Elle donne une base factuelle aux décisions, en précisant ce qui fonctionne, ce qui bloque et ce qui doit être conservé, adapté ou remplacé.
Ce que recouvre vraiment l’analyse de l’existant
L’analyse de l’existant est une démarche d’observation structurée. Elle ne consiste pas seulement à décrire un outil en place ou à lister des irritants métier. Elle vise à documenter l’environnement réel dans lequel l’organisation fonctionne : processus, flux de travail, système d’information, règles internes, contraintes externes et responsabilités des acteurs.
Une photographie utile, pas un inventaire passif
Une bonne analyse de l’existant ne se limite pas à dire « voici ce qui existe ». Elle explique comment les activités s’enchaînent, qui intervient, quelles données circulent, quels systèmes communiquent entre eux et où se situent les dépendances. Elle doit aussi faire apparaître les points solides de la situation actuelle : une pratique efficace, une automatisation fiable, une connaissance métier clé ou une règle de gestion indispensable.
Tout projet de transformation ne part pas d’une page blanche. Certaines composantes de l’existant sont à préserver, car elles soutiennent des besoins métier critiques. D’autres doivent être corrigées, simplifiées ou supprimées parce qu’elles ralentissent l’activité ou créent des risques.
Le lien avec l’analyse des besoins et l’analyse des écarts
L’analyse de l’existant prépare directement l’analyse des besoins. Avant de demander « que veut-on demain ? », il faut comprendre « comment fonctionne-t-on aujourd’hui ? ». C’est aussi la base de l’analyse des écarts : une fois la solution cible définie, on compare la situation actuelle et la situation souhaitée pour identifier les changements nécessaires.
Sans cette étape, les besoins exprimés risquent d’être incomplets, contradictoires ou influencés par une vision partielle du terrain. À l’inverse, une analyse documentée permet de distinguer un vrai besoin métier d’une préférence d’outil ou d’une habitude héritée.
Les 5 questions à traiter avant de proposer une solution
Pour être exploitable, l’analyse de l’existant doit répondre à quelques questions structurantes. Elles servent de fil conducteur pendant les entretiens, l’audit documentaire, les ateliers avec les parties prenantes et l’observation des usages.
| Thème | Questions à poser | Ce que l’on cherche à comprendre |
|---|---|---|
| Contexte | Dans quel environnement évolue l’organisation ? Existe-t-il un cadre réglementaire, légal ou stratégique ? | Les contraintes qui conditionnent le projet et les limites à respecter. |
| Acteurs | Qui réalise, approuve, consulte ou reçoit l’information ? Les équipes sont-elles sur un site, dispersées ou en sous-traitance ? | Les responsabilités, les circuits de décision et les modes de collaboration. |
| Processus | Quels sont les flux de travail actuels ? Où apparaissent les ruptures, les doublons ou les validations inutiles ? | La réalité opérationnelle et les points de friction. |
| Système d’information | Quelle est l’architecture actuelle ? Quels systèmes internes ou externes interagissent ? | Les interdépendances techniques, les interfaces et les risques d’impact. |
| Besoins métier | Quels besoins critiques sont couverts aujourd’hui ? Quels besoins secondaires influencent la performance ? | Ce qui doit absolument être maintenu ou amélioré dans la solution cible. |
Ne pas confondre contrainte et préférence
Une erreur fréquente consiste à placer au même niveau une obligation réglementaire, une règle de sécurité, une habitude utilisateur et une préférence ergonomique. L’analyse doit hiérarchiser ces éléments. Une contrainte légale est non négociable ; une préférence d’interface peut être discutée ; une limitation technique peut être contournée ou intégrée au plan de transition.
Cette distinction évite de figer trop tôt la solution cible. Elle permet aussi de clarifier les arbitrages avec les décideurs : ce qui relève du respect obligatoire, de l’optimisation opérationnelle ou du confort d’usage.
Comment collecter une information fiable et exploitable
La qualité de l’analyse dépend moins du volume d’informations collectées que de leur fiabilité. Il faut croiser les points de vue, vérifier les documents existants et confronter les déclarations aux pratiques réelles. Un processus décrit dans une procédure peut être très différent de celui appliqué au quotidien.
Combiner entretiens, observation et documentation
Les entretiens avec les parties prenantes permettent de comprendre les objectifs, les irritants et les contraintes perçues. L’observation terrain révèle les contournements, les doubles saisies, les fichiers parallèles et les validations informelles. Les documents existants, eux, apportent une base de référence : procédures, cartographies applicatives, organigrammes, contrats de service, règles de gestion ou rapports d’incident.
Le plus efficace est de structurer la collecte par thème : processus, acteurs, données, applications, règles, risques et performances attendues. Chaque information doit être reliée à une preuve ou à une personne référente. Cela renforce la traçabilité et facilite la validation finale.
Valider avec les parties prenantes
Une analyse de l’existant ne devrait pas rester dans le bureau du business analyst, du chef de projet ou du consultant. Elle doit être relue par les parties prenantes concernées : utilisateurs clés, responsables métier, équipes informatiques, conformité, support, direction opérationnelle. Cette validation permet de corriger les angles morts et d’éviter les malentendus.
La cartographie des flux, des dépendances applicatives, des validations humaines et des règles tacites aide à repérer les zones sensibles. Dans un projet, ces éléments peuvent être simples à décrire, mais ils conditionnent souvent la fiabilité de l’ensemble.
Les livrables attendus d’une analyse de l’existant
Le livrable principal est généralement un rapport d’analyse, mais celui-ci peut prendre plusieurs formes selon la taille du projet. L’objectif n’est pas de produire un document long : il est de rendre l’existant compréhensible, vérifiable et réutilisable pour la suite du projet.
Le rapport d’analyse
Le rapport d’analyse présente le périmètre audité, les méthodes de collecte, les constats majeurs et les limites connues. Il doit expliciter le contexte réglementaire, légal et stratégique lorsque ces éléments influencent le projet. Il inclut aussi les processus existants, les acteurs impliqués, les solutions informatiques utilisées, les interactions entre systèmes et les besoins métier actuellement couverts.
Un bon rapport sépare les faits, les interprétations et les recommandations. Par exemple, « la saisie est réalisée deux fois dans deux applications » est un fait ; « cela génère une perte d’efficacité » est une interprétation à étayer ; « unifier la saisie dans un seul point d’entrée » est une recommandation possible.
Les cartographies et matrices utiles
Selon le projet, plusieurs livrables complémentaires peuvent rendre l’analyse plus lisible : cartographie des processus, schéma d’architecture actuelle, matrice des acteurs, inventaire applicatif, liste des contraintes, registre des irritants, tableau des dépendances ou synthèse des fonctionnalités existantes.
- Cartographie des processus : visualiser les étapes, les acteurs, les entrées, les sorties et les points de rupture.
- Inventaire des applications : identifier les outils, les propriétaires, les usages, les interfaces et les limites.
- Matrice des parties prenantes : distinguer réalisateurs, approbateurs, consultés et informés.
- Liste des besoins couverts : séparer besoins critiques, secondaires et non couverts.
- Synthèse des écarts pressentis : préparer la comparaison avec la solution cible.
Passer du diagnostic aux recommandations
L’analyse de l’existant n’a de valeur que si elle nourrit une décision. Une fois les constats validés, il faut les traduire en enjeux, puis en recommandations. Ce passage doit rester prudent : l’analyse ne remplace pas encore la conception détaillée de la solution, mais elle oriente les priorités.
Prioriser les constats
Tous les constats ne méritent pas le même niveau d’attention. Il est utile de les classer selon leur criticité métier, leur impact sur les utilisateurs, leur risque réglementaire, leur complexité technique et leur fréquence d’apparition. Un irritant quotidien qui touche toute une équipe peut être plus prioritaire qu’une anomalie rare mais visible dans un rapport de direction.
Cette priorisation prépare le plan d’amélioration. Elle aide à distinguer les actions rapides, les sujets à approfondir et les transformations plus lourdes qui demanderont une étude complémentaire.
Formuler des recommandations actionnables
Une recommandation efficace indique le problème traité, l’objectif visé et la prochaine étape. Elle peut proposer de simplifier un processus, supprimer une double saisie, clarifier une responsabilité, fiabiliser une interface, documenter une règle métier ou lancer un atelier de cadrage sur un besoin non couvert.
Enfin, l’analyse doit rester vivante. Lorsque de nouvelles informations apparaissent pendant le projet, les données collectées peuvent être mises à jour. Cette mise à jour continue évite que le diagnostic initial devienne obsolète et maintient un lien cohérent entre audit, besoins, écarts, recommandations et plan d’amélioration.