Analyse de l’existant : méthode, questions et livrables pour cadrer un projet

L’analyse de l’existant est la phase d’audit qui décrit, avant tout changement, la façon dont une organisation fonctionne réellement : ses processus, ses acteurs, ses outils, ses données et ses contraintes. Elle se réalise en amont du projet, avant l’analyse des besoins, et sert de point de référence pour mesurer les écarts avec la solution cible. Concrètement, il s’agit de collecter des informations fiables, d’interroger les parties prenantes, de cartographier l’architecture actuelle puis de livrer un rapport d’analyse assorti de recommandations. Sans ce socle, un projet de transformation repose sur des suppositions.

Analyse de l’existant : définition et place dans le cycle d’un projet

Dans le vocabulaire du business analyst comme dans celui des mémoires de fin d’études en informatique, l’analyse de l’existant désigne l’étude de ce qui fonctionne aujourd’hui, avec ses forces et ses faiblesses. On parle aussi d’étude de l’existant, d’état des lieux ou de diagnostic. La critique de l’existant, souvent présentée comme un chapitre distinct, en constitue le prolongement évaluatif : après avoir décrit, on juge.

Cette étape occupe une position charnière. Elle ne cherche pas encore à dessiner la solution cible ; elle établit une photographie fidèle, partagée et vérifiable de la situation de départ. C’est cette photographie qui rendra ensuite possible une discussion rationnelle sur ce qu’il faut garder, corriger ou remplacer.

Ce que l’audit de l’existant évite à une organisation

Lancer un projet sans regarder l’existant revient à construire une stratégie à l’aveugle. Les conséquences sont connues des chefs de projet : une fonctionnalité utilisée quotidiennement disparaît dans la nouvelle version, une contrainte légale est découverte en recette, une interface avec un partenaire externe casse au moment de la bascule.

L’audit apporte plusieurs bénéfices concrets :

• il identifie les points forts à préserver, pas seulement les dysfonctionnements ;
• il révèle les interdépendances entre systèmes, souvent invisibles dans la documentation officielle ;
• il aligne les parties prenantes sur un constat commun, ce qui apaise les débats ultérieurs ;
• il fournit une base mesurable pour évaluer, après déploiement, si la transformation a réellement amélioré la situation ;
• il prépare l’analyse des besoins en distinguant les attentes réelles des habitudes héritées.

Ce dernier point est sous-estimé. Une partie des « besoins » exprimés par les utilisateurs ne sont que des contournements d’un outil défaillant. L’analyse de l’existant permet de remonter à la cause, et donc de ne pas reproduire un défaut dans la solution suivante.

À quel moment réaliser l’analyse de l’existant dans un projet

La règle est simple : l’analyse intervient pendant la phase amont, avant l’initialisation du changement. Elle suit la note de cadrage (qui fixe les objectifs et le périmètre) et précède toute rédaction de cahier des charges. Dans une démarche agile, elle prend la forme d’un sprint de découverte plutôt que d’un document figé, mais sa fonction reste identique.

Deux situations justifient de la relancer en cours de route : un changement de périmètre important, ou la découverte d’un système non répertorié. C’est pourquoi les méthodes les plus abouties prévoient une mise à jour continue des données collectées, plutôt qu’un audit ponctuel archivé dès sa remise.

Le périmètre d’audit : les informations à collecter

Le périmètre se construit autour de six blocs. Chacun répond à une question précise et s’appuie sur des sources différentes. Le tableau ci-dessous peut servir de checklist de collecte.

Un septième bloc s’ajoute souvent dans les projets de système d’information : les données elles-mêmes. Volumes, qualité, doublons, règles de gestion et documents circulants (factures, bons, fiches) méritent un inventaire, car la migration des données reste l’une des principales sources de retard.

Questions à poser aux parties prenantes

Les entretiens constituent le cœur de la collecte. Chaque profil détient une partie de la vérité, et les questions doivent être adaptées à son niveau de responsabilité.

Interroger les décideurs et les approbateurs

• Quels objectifs stratégiques le projet doit-il servir dans les trois prochaines années ?
• Quelles obligations réglementaires ou contractuelles s’imposent au périmètre étudié ?
• Qui valide les décisions, et selon quel circuit ?
• Quels indicateurs suivez-vous aujourd’hui pour juger que l’activité fonctionne bien ?

Interroger les utilisateurs opérationnels

• Pouvez-vous me montrer, sur votre poste, comment vous traitez un cas courant ?
• Quelles tâches faites-vous en dehors de l’outil (tableur, papier, messagerie) ?
• Où perdez-vous le plus de temps chaque semaine ?
• Quelle fonctionnalité ne doit surtout pas disparaître ?

Interroger les équipes techniques et les prestataires

• Quels systèmes échangent des données avec l’application étudiée, et par quel moyen ?
• Quelles briques sont en fin de support ou dépendent d’un prestataire unique ?
• Quels incidents reviennent le plus souvent ?

Sur la forme, un entretien individuel de 45 à 60 minutes donne de meilleurs résultats qu’un atelier collectif pour cette phase, car chacun s’exprime sans filtre hiérarchique. Préparez une grille, mais laissez la personne dérouler son quotidien : les informations les plus utiles apparaissent souvent au détour d’une anecdote. Enfin, croisez toujours ce qui est dit avec ce qui est observé. Une procédure décrite en entretien diffère régulièrement de la pratique réelle au poste de travail.

Déroulé d’une analyse de l’existant, de la collecte à la validation

1. Cadrer : fixer le périmètre, la liste des interlocuteurs, le calendrier et le format des livrables.
2. Collecter la documentation : procédures, schémas, contrats, rapports d’incidents, exports de données.
3. Mener entretiens et observations : suivre la grille de questions et noter les écarts entre discours et pratique.
4. Cartographier : traduire la matière recueillie en schémas de processus, d’acteurs et d’architecture.
5. Examiner : repérer forces, faiblesses, risques et redondances.
6. Valider : organiser une session de restitution avec les parties prenantes pour corriger les erreurs d’interprétation.
7. Documenter et mettre à jour : rédiger le rapport, puis le tenir à jour jusqu’à la conception de la solution.

La session de restitution mérite une attention particulière. Présentez d’abord les schémas, pas les critiques : un acteur qui reconnaît son processus dans une cartographie accepte plus facilement le diagnostic qui suit. Prévoyez un temps de correction à chaud et une seconde version envoyée par écrit, avec un délai de relecture fixé.

Prioriser les informations recueillies

Un audit produit toujours plus de matière qu’il n’en faut. Pour éviter un rapport de cent pages que personne ne lira, chaque constat peut être évalué selon cinq critères de qualité.

Les constats critiques, cohérents et traçables vont dans le corps du rapport. Les autres rejoignent une annexe, ce qui préserve l’information sans alourdir la lecture.

Les livrables de l’analyse de l’existant

Les concurrents évoquent les livrables sans jamais les détailler. Voici ceux que l’on attend d’une analyse aboutie :

• Cartographie des acteurs : une matrice précisant qui est responsable, qui approuve, qui est consulté et qui est informé.
• Cartographie des processus : un schéma par processus clé, avec les points de décision et les irritants signalés.
• Schéma d’architecture actuelle : applications, flux de données et interactions système-acteurs.
• Inventaire fonctionnel : chaque fonctionnalité de la solution existante, son taux d’usage et son niveau de satisfaction.
• Registre des irritants et des risques : classé par criticité.
• Rapport d’analyse et recommandations : la synthèse destinée aux décideurs.

Pour le rapport, une trame efficace tient en sept parties : contexte et objectifs de l’audit ; méthode et sources ; présentation de l’organisation et des acteurs ; description des processus et de l’architecture ; points forts ; points faibles et risques ; recommandations et prochaines étapes. Une page de synthèse en ouverture, lisible en deux minutes, permet aux approbateurs de décider sans parcourir l’ensemble.

De l’existant à l’analyse des écarts et au plan d’amélioration

La chaîne logique est la suivante : collecte, rapport, recommandations, plan d’amélioration. Une fois l’analyse des besoins menée, chaque besoin est confronté à l’état des lieux. Trois cas se présentent : le besoin est déjà couvert (on conserve), il est partiellement couvert (on adapte), ou il n’est pas couvert du tout (on développe ou on acquiert). C’est l’analyse des écarts.

Les recommandations découlent de ces écarts et doivent être formulées de manière actionnable : un responsable, une échéance, un effort estimé. Le plan d’amélioration regroupe ensuite ces initiatives en lots, en commençant généralement par les écarts critiques qui demandent peu d’effort. Cette logique s’inscrit dans une démarche d’amélioration continue : l’état des lieux d’aujourd’hui devient la référence de comparaison du prochain audit, ce qui intègre l’analyse dans la gouvernance de projet et dans la gestion du changement.

Exemple d’analyse de l’existant : un média de pronostics sportifs refond son suivi

Pour rendre la méthode tangible, prenons un cas proche de notre univers. Un site qui publie des avis sur des services de pronostics décide de remplacer son système de suivi des résultats, devenu difficile à maintenir. Avant de choisir un nouvel outil, l’équipe lance une analyse de l’existant.

La collecte révèle d’abord une architecture fragmentée : les résultats des tipsters sont saisis à la main dans plusieurs tableurs, puis recopiés dans les pages d’avis. L’inventaire fonctionnel montre que les fiches consacrées à onze pronos ou à iwin pronos reposent chacune sur un fichier différent, avec des colonnes qui ne portent pas le même nom. Les entretiens avec les rédacteurs font ressortir un irritant majeur : aucune date de mise à jour commune, si bien qu’un lecteur ne peut pas savoir si deux bilans couvrent la même période.

L’observation des postes apporte une découverte inattendue. Une rédactrice tient un fichier personnel croisant les statistiques de buts par période, celui qui alimente la page sur la mi temps la plus prolifique. Ce fichier n’apparaissait dans aucune documentation, alors qu’il constitue une source de données réutilisable. Sans audit, il aurait été perdu lors de la migration.

Le rapport d’analyse conclut à trois recommandations : unifier le format de saisie, centraliser les historiques dans une base unique et fixer une règle de traçabilité pour chaque pari enregistré. L’analyse des écarts montre que la nouvelle grille d’Analyse de performance exige des données horodatées que l’ancien système ne fournissait pas. Le plan d’amélioration prévoit donc un premier lot pilote sur un seul service, par exemple l’avis pronosmax, avant d’étendre la méthode à l’ensemble des fiches.

Ce scénario illustre un point souvent négligé : l’analyse de l’existant ne concerne pas uniquement les grands systèmes d’information. Toute organisation qui s’appuie sur des données, même modestes, gagne à documenter ses pratiques avant de les transformer.

Erreurs fréquentes lors d’une analyse de l’existant

• Se contenter de la documentation officielle : elle décrit le fonctionnement prévu, rarement le fonctionnement réel.
• N’interroger que les managers : les utilisateurs de terrain connaissent les contournements et les irritants quotidiens.
• Juger trop tôt : mêler description et critique dès les entretiens braque les interlocuteurs et biaise les réponses.
• Oublier les flux externes : partenaires, sous-traitants et organismes de contrôle échangent souvent des données critiques.
• Négliger les points forts : un rapport uniquement à charge pousse à tout remplacer, y compris ce qui fonctionne.
• Livrer sans restitution : un rapport non validé par les parties prenantes perd sa légitimité dès la première contestation.
• Archiver le document : un état des lieux figé devient obsolète en quelques mois sur un projet long.

Bien conduite, cette phase transforme une intuition (« notre outil ne convient plus ») en constat argumenté, partagé et chiffré. Elle donne au projet un point de départ que personne ne conteste, et c’est précisément ce qui permet ensuite de décider vite.