Analyse de l’existant : questions, livrables, écarts

L’analyse de l’existant sert à comprendre la situation actuelle avant de concevoir une solution cible. Elle intervient en amont d’un projet, souvent avant le lancement du changement, pour auditer les processus, les outils, les acteurs, les contraintes et les besoins métier déjà couverts. Bien menée, elle évite de bâtir une stratégie sur des suppositions et prépare l’analyse des besoins puis l’analyse des écarts.

Table des matières

À quoi sert l’analyse de l’existant dans un projet ?

L’analyse de l’existant est une phase de diagnostic. Elle consiste à observer, documenter et qualifier le fonctionnement actuel d’une organisation, d’un service, d’un processus ou d’un système d’information. Son objectif n’est pas de choisir une solution tout de suite, mais de comprendre ce qui fonctionne, ce qui bloque, ce qui dépend d’autres éléments et ce qui doit être préservé. Elle donne un point de départ clair.

Dans un projet de transformation, elle sert de base de travail. Sans cette base, l’analyse des besoins risque de mêler les attentes réelles, les irritants ponctuels et les préférences individuelles. L’analyse de l’existant permet au contraire de distinguer les faits observables des opinions, puis de relier chaque demande à un contexte opérationnel concret. C’est ce cadrage qui évite les décisions prises trop tôt.

Une étape à placer avant la solution cible

Cette analyse doit être réalisée avant de formaliser une cible détaillée. À ce stade, il s’agit de répondre à des questions simples mais structurantes : comment le travail est-il fait aujourd’hui ? Quels outils sont utilisés ? Qui intervient ? Quelles contraintes encadrent les décisions ? Quels processus sont critiques pour l’activité ? Ces réponses donnent un cadre solide pour la suite.

Elle est particulièrement utile lorsqu’un projet touche plusieurs équipes, plusieurs applications ou plusieurs sites. Dans ces situations, les écarts de pratiques sont fréquents : deux services peuvent utiliser le même outil avec des règles différentes, ou suivre le même processus avec des validations différentes. L’analyse de l’existant rend ces différences visibles avant qu’elles ne deviennent des risques projet. Elle aide aussi à éviter les malentendus entre métiers et technique.

Définir le périmètre d’audit sans se disperser

Une analyse pertinente ne consiste pas à tout documenter. Elle consiste à documenter ce qui éclaire la décision. Le périmètre doit donc être cadré dès le départ : processus concernés, applications incluses, populations utilisatrices, zones géographiques, contraintes réglementaires, dépendances techniques et limites connues. Ce cadrage limite les doublons et garde le focus sur l’utile.

Le bon réflexe consiste à séparer trois niveaux : le contexte de l’organisation, le fonctionnement métier et l’environnement technique. Cette séparation évite de réduire l’analyse à une cartographie informatique ou, à l’inverse, à une simple liste de difficultés métier sans compréhension des systèmes qui les supportent. Elle permet aussi de relier chaque observation à un impact réel.

Contexte, contraintes et stratégie

L’analyse doit d’abord situer l’organisation dans son environnement. Existe-t-il un cadre réglementaire ou légal à respecter ? Le projet doit-il s’aligner sur un plan stratégique, une politique groupe, une trajectoire de réduction des coûts, une exigence de conformité ou une réorganisation interne ? Ces éléments conditionnent souvent les choix futurs. Ils fixent les marges de manœuvre.

Il faut aussi identifier les limitations internes et externes : budget, délais, dette technique, contrats en cours, dépendance à un fournisseur, disponibilité des équipes, sous-traitance, dispersion géographique des collaborateurs. Ces contraintes ne sont pas des détails administratifs ; elles définissent le niveau de réalisme de la solution cible. Les ignorer revient à construire un projet difficile à tenir.

Processus, flux et systèmes existants

L’audit des processus existants doit décrire les grandes étapes du travail, les points de décision, les validations, les exceptions et les irritants. Il est utile de repérer les flux de travail réels, pas seulement ceux qui figurent dans les procédures officielles. Les contournements, les fichiers parallèles et les doubles saisies révèlent souvent les limites de la solution actuelle. Ils montrent où se perd du temps.

Côté système d’information, l’analyse porte sur l’architecture actuelle, les solutions informatiques existantes, les données manipulées et les interactions entre systèmes. Les interdépendances avec des applications externes doivent être explicitées : imports, exports, API, ressaisies, synchronisations manuelles, règles de gestion partagées. Plus cette lecture est précise, plus la cible sera crédible.

Une bonne façon de prioriser consiste à chercher la structure qui porte réellement l’activité. Dans une organisation, cela peut être un référentiel client, un processus de validation, un planning de production ou une règle de facturation. Si cette structure se dégrade, tout le reste devient plus fragile. L’identifier permet de distinguer ce qui est simplement inconfortable de ce qui est vital pour la continuité opérationnelle.

Les questions à poser aux parties prenantes

La collecte ne doit pas reposer uniquement sur la documentation disponible. Les procédures, schémas d’architecture et modes opératoires donnent une première vision, mais les entretiens avec les parties prenantes permettent de comprendre l’usage réel. Il faut interroger les réalisateurs, les approbateurs, les utilisateurs consultés et les personnes simplement informées. Cette diversité de points de vue évite les angles morts.

La validation par les parties prenantes est essentielle : elle permet de corriger les écarts, de confirmer les observations et d’éviter qu’un rapport soit perçu comme théorique. Un atelier de restitution intermédiaire est souvent plus efficace qu’une validation tardive, car il permet d’ajuster l’analyse avant la rédaction finale. Cela réduit aussi les retours de dernière minute.

Thème d’analyse	Questions utiles	Ce que l’on cherche à comprendre
Acteurs	Qui réalise, valide, consulte ou reçoit l’information ?	Les responsabilités, les doublons et les points de blocage.
Processus	Quelles étapes sont indispensables et lesquelles sont contournées ?	Le fonctionnement réel, les exceptions et les irritants.
Systèmes	Quels outils supportent le processus et comment communiquent-ils ?	L’architecture actuelle et les interdépendances techniques.
Besoins métier	Quels besoins critiques sont déjà couverts ? Lesquels le sont mal ?	La différence entre besoins vitaux, secondaires et non couverts.
Contraintes	Quelles règles réglementaires, légales ou stratégiques s’imposent ?	Les limites à intégrer avant toute recommandation.

Faire émerger les besoins critiques et secondaires

Un besoin métier critique est un besoin sans lequel l’organisation ne peut pas fonctionner correctement. Il peut s’agir de produire une facture, valider une commande, tracer une intervention, sécuriser un accès ou consolider une donnée de référence. Ces besoins doivent être distingués des besoins secondaires, qui améliorent la performance sans bloquer immédiatement l’activité. Cette hiérarchie évite de confondre confort et nécessité.

Cette distinction compte pour la suite du projet. Elle permet de hiérarchiser les écarts et d’éviter que des demandes visibles, mais peu critiques, prennent le dessus sur des problèmes structurels. L’analyse de l’existant doit donc qualifier l’impact métier, la fréquence, les populations concernées et les risques associés. C’est cette lecture qui aide à décider quoi traiter en priorité.

Les livrables attendus : du constat aux écarts

Les livrables de l’analyse de l’existant doivent être exploitables par les décideurs, les métiers, les équipes projet et, si nécessaire, les équipes techniques. Leur forme dépend du projet, mais leur logique reste la même : présenter les faits, les organiser, les faire valider, puis préparer les écarts avec la cible. Un bon livrable doit pouvoir servir sans traduction supplémentaire.

Un rapport d’analyse efficace ne se limite pas à une description. Il met en évidence les forces, les faiblesses, les dépendances et les risques. Il doit permettre de comprendre rapidement ce qui doit être conservé, simplifié, remplacé, automatisé ou approfondi lors de l’analyse des besoins. Sa valeur tient à sa lisibilité autant qu’à sa précision.

Les livrables les plus utiles

Une note de cadrage de l’existant : périmètre, objectifs, acteurs interrogés, limites de l’analyse.
Une cartographie des processus : étapes, rôles, validations, points de friction et exceptions.
Une synthèse de l’architecture actuelle : applications, flux, données, interdépendances avec les systèmes externes.
Une matrice acteurs-responsabilités : réalisateurs, approbateurs, consultés et informés.
Une liste des besoins couverts et non couverts : besoins critiques, secondaires, irritants et limites fonctionnelles.
Un rapport d’analyse et recommandations : constats priorisés, risques, opportunités et premières pistes d’amélioration.

L’analyse des écarts intervient ensuite pour comparer l’existant à la solution cible. Elle ne doit pas être confondue avec l’analyse de l’existant : la première décrit la situation actuelle, la seconde mesure la distance entre cette situation et l’objectif à atteindre. Plus le diagnostic initial est précis, plus l’analyse des écarts sera fiable. C’est ce lien qui donne de la cohérence au projet.

Rédiger une analyse claire et actionnable

La qualité d’une analyse de l’existant dépend autant de la collecte que de la rédaction. Un document trop descriptif devient vite lourd ; un document trop synthétique perd sa valeur de preuve. Le bon équilibre consiste à structurer l’information par thèmes, à citer les constats importants et à relier chaque observation à un impact métier ou projet. La clarté prime sur l’effet de style.

Une trame simple à réutiliser

Rappeler le périmètre : ce qui est inclus, exclu et les hypothèses retenues.
Décrire le contexte : contraintes réglementaires, légales, stratégiques et organisationnelles.
Présenter les acteurs : rôles, responsabilités, répartition géographique et modes de collaboration.
Analyser les processus : étapes, flux de travail, irritants, exceptions et dépendances.
Documenter le système d’information : outils, données, architecture actuelle et interactions entre systèmes.
Qualifier les besoins métier : besoins critiques, besoins secondaires, fonctionnalités existantes et limites.
Conclure par les constats prioritaires : forces, faiblesses, risques et recommandations.

La mise à jour continue des données est également importante lorsque l’analyse s’étale dans le temps. Un changement d’organisation, une nouvelle contrainte ou une évolution technique peut rendre une partie du diagnostic obsolète. Il est donc préférable d’indiquer la date des observations, les personnes consultées et les points restant à confirmer. Cette trace facilite la reprise du dossier.

Enfin, une bonne restitution doit rester orientée décision. Elle ne cherche pas à démontrer que tout a été étudié, mais à rendre visible ce qui compte pour la suite : les écarts probables, les arbitrages à prévoir, les risques à maîtriser et les initiatives d’amélioration à planifier. C’est à ce moment que l’analyse de l’existant devient un outil de pilotage du changement.