Analyse de l’existant : 5 questions clés

L’analyse de l’existant intervient avant de concevoir une solution cible, de rédiger des besoins détaillés ou de lancer un changement. Son objectif est clair : comprendre ce qui fonctionne aujourd’hui, ce qui bloque, qui est concerné, quelles contraintes s’imposent et sur quelles bases réelles le projet doit s’appuyer.

Dans un projet métier, digital ou organisationnel, cette phase évite de décider à l’aveugle. Elle transforme des impressions dispersées en constats vérifiables : processus utilisés, solutions informatiques en place, flux de travail, interactions entre systèmes, besoins métier couverts ou non, limites internes et externes. Bien menée, elle prépare directement l’analyse des besoins et l’analyse des écarts.

Table des matières

Ce que recouvre vraiment l’analyse de l’existant

L’analyse de l’existant est un audit structuré de la situation actuelle sur un périmètre donné. Elle ne consiste pas seulement à décrire un outil ou à lister des irritants. Elle cherche à comprendre l’organisation dans son environnement : ses objectifs, ses règles, ses acteurs, ses processus, son système d’information et ses usages réels.

Une phase amont, avant l’initialisation du changement

Elle se place en amont du projet, avant que les choix de solution ne soient figés. C’est ce positionnement qui lui donne sa valeur : elle permet de distinguer ce qui relève d’un besoin métier, d’une contrainte technique, d’une habitude historique ou d’un problème de gouvernance. Sans cette étape, une organisation risque de moderniser un processus mal compris ou de remplacer un outil sans traiter la cause réelle des difficultés.

Un lien direct avec l’analyse des besoins et des écarts

L’analyse de l’existant répond à une question de départ : « Où en sommes-nous réellement ? » L’analyse des besoins répond ensuite : « De quoi avons-nous besoin ? » Puis l’analyse des écarts compare la situation actuelle avec la situation cible. Ces trois étapes sont liées. Un besoin bien formulé s’appuie sur un constat solide, et un écart pertinent ne peut être mesuré que si l’existant a été documenté avec précision.

Les informations à collecter sans se perdre dans les détails

Le risque principal d’une analyse de l’existant est de tout vouloir documenter. Or une bonne analyse n’est pas une encyclopédie interne : elle sélectionne les informations utiles à la décision. Le bon niveau de détail dépend du périmètre du projet, de la criticité des processus et des décisions à prendre ensuite.

Le contexte réglementaire, légal et stratégique

Commencez par le cadre dans lequel évolue l’organisation. Existe-t-il des obligations réglementaires ou légales qui limitent les options possibles ? Le projet doit-il s’aligner sur un plan stratégique, une feuille de route groupe, une politique de sécurité, une contrainte de conformité ou un modèle opérationnel déjà validé ? Ces éléments évitent de recommander une cible séduisante mais incompatible avec la réalité de l’entreprise.

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

L’analyse doit identifier les parties prenantes : utilisateurs finaux, responsables métier, approbateurs, équipes IT, support, sous-traitants, décideurs, personnes consultées ou simplement informées. Il faut aussi comprendre comment ces acteurs interagissent avec les systèmes : qui saisit l’information, qui la valide, qui la transforme, qui l’exploite et qui subit les erreurs éventuelles.

Un détail souvent révélateur tient à la géographie du travail. Des collaborateurs sur un même site n’ont pas les mêmes contraintes que des équipes dispersées, externalisées ou organisées par fuseaux horaires. Les circuits de validation, les délais de réponse, les doublons de saisie et les pertes d’information apparaissent souvent dans ces zones de friction. C’est là que les écarts entre organisation prescrite et organisation réelle deviennent visibles.

Les processus, outils et fonctionnalités réellement utilisés

L’audit doit couvrir les processus existants, les solutions informatiques en place, les flux de travail et les fonctionnalités de la solution actuelle. Mais il faut distinguer l’usage théorique de l’usage réel. Une fonctionnalité peut exister sans être utilisée, être contournée par un fichier local, ou être réservée à une équipe alors qu’elle devrait soutenir l’ensemble du processus.

Un dysfonctionnement apparaît rarement au moment où il devient visible. Il commence souvent comme une petite exception tolérée : un champ mal renseigné, une validation faite par e-mail, une extraction manuelle « en attendant », une règle métier connue d’une seule personne. L’analyse de l’existant doit repérer ces micro-déviations, car elles alimentent souvent les retards, les erreurs de reporting ou les résistances futures au changement.

Les 5 questions qui structurent un audit pertinent

Pour rester opérationnelle, l’analyse peut être conduite autour de 5 familles de questions. Elles servent de grille d’entretien, de support d’atelier et de base pour organiser les constats dans le rapport d’analyse.

Thème	Questions à poser	Ce que cela permet d’identifier
Environnement	Dans quel contexte l’organisation évolue-t-elle ? Quelles contraintes réglementaires, légales ou stratégiques s’appliquent ?	Les limites à respecter et les décisions déjà cadrées.
Acteurs	Qui réalise, approuve, consulte ou reçoit l’information ? Où sont situées les équipes ?	Les responsabilités, les dépendances humaines et les points de friction.
Processus	Quelles étapes sont suivies aujourd’hui ? Quels contournements existent ?	Les forces, faiblesses, doublons et ruptures de flux.
Système d’information	Quelle est l’architecture actuelle ? Quels systèmes communiquent entre eux ou avec l’extérieur ?	Les interdépendances, les risques techniques et les impacts d’évolution.
Besoins métier	Quels besoins critiques sont couverts ? Quels besoins secondaires influencent la performance ?	Les priorités métier et les écarts à analyser ensuite.

Cette grille n’est pas figée. Dans un projet très technique, l’architecture du système d’information et les interdépendances avec les systèmes externes prendront plus de place. Dans un projet d’organisation, les rôles, les validations et les flux de travail seront souvent plus structurants. L’essentiel est de garder un cadre lisible et de ne pas multiplier les questions sans lien avec la décision à prendre.

La méthode pour collecter, valider et fiabiliser les constats

Une analyse de l’existant fiable combine plusieurs modes de collecte. Les entretiens donnent accès aux usages et aux irritants. Les ateliers confrontent les points de vue. La documentation existante permet de vérifier les règles, les schémas, les procédures et les décisions antérieures. L’observation terrain, quand elle est possible, révèle les écarts entre processus officiel et pratique réelle.

Collecter sans confondre opinion et fait

Un entretien peut produire des informations très utiles, mais aussi des perceptions subjectives. Une phrase comme « l’outil ne fonctionne jamais » doit être reformulée en élément vérifiable : quelle fonctionnalité est concernée, à quelle fréquence, pour quels utilisateurs, avec quel impact métier ? Cette discipline évite de transformer des frustrations légitimes en diagnostic approximatif.

Faire valider par les parties prenantes

La validation par les parties prenantes est essentielle. Elle permet de corriger les oublis, d’arbitrer les divergences et de sécuriser l’adhésion au diagnostic. Il ne s’agit pas de chercher un consensus artificiel, mais de faire reconnaître les faits : périmètre, processus observés, contraintes, limites, dépendances, points forts et points faibles.

Cette validation peut prendre la forme d’un atelier de restitution, d’une revue de document ou d’une cartographie commentée. L’important est de garder une trace des hypothèses, des désaccords et des points à confirmer. Une mise à jour continue des données est parfois nécessaire lorsque le projet s’étale ou que l’organisation évolue pendant l’audit.

Les livrables attendus et le passage vers l’amélioration

Le livrable principal est généralement un rapport d’analyse de l’existant. Il doit être clair, exploitable et orienté décision. Sa valeur ne tient pas au volume, mais à sa capacité à relier les observations aux enjeux du projet.

Ce que doit contenir le rapport d’analyse

Un rapport efficace présente le périmètre étudié, la méthode de collecte, les parties prenantes rencontrées, les processus analysés, les solutions informatiques existantes, l’architecture actuelle, les interactions entre systèmes, les besoins métier couverts et les limitations identifiées. Il peut inclure des cartographies de processus, une matrice des acteurs, une synthèse des irritants et une liste des dépendances critiques.

Constats factuels : ce qui existe, comment cela fonctionne, avec quelles contraintes.
Forces de l’existant : pratiques efficaces, outils utiles, savoir-faire à préserver.
Faiblesses et limites : doublons, ruptures de flux, dépendances, risques, lenteurs.
Impacts métier : effets sur la qualité, les délais, la conformité, la performance ou l’expérience utilisateur.
Points à approfondir : informations manquantes, hypothèses à confirmer, arbitrages nécessaires.

Transformer l’audit en recommandations

L’analyse ne doit pas s’arrêter au diagnostic. Elle prépare les recommandations, l’analyse des écarts et le plan d’amélioration. Une recommandation pertinente relie toujours un constat à un objectif : simplifier un flux, réduire une ressaisie, sécuriser une validation, clarifier une responsabilité, moderniser une intégration ou mieux couvrir un besoin métier critique.

La dernière étape consiste à prioriser. Tous les problèmes repérés ne méritent pas le même traitement. Les critères utiles sont la criticité métier, le risque opérationnel, la fréquence du problème, le nombre d’acteurs touchés, la dépendance technique et l’alignement avec la stratégie. Cette priorisation fait de l’analyse de l’existant un véritable outil de décision, et non un simple état des lieux documentaire.