Webinaire Nouvelle norme ISO 9001 : à quelles évolutions s'attendre ? - 17/09/2026 - 16h S'inscrire

Transformer son organisation : avez-vous pensé à la méthode AS IS / TO BE ?

Modéliser des processus idéaux que personne n’appliquera est le danger de nombreux projets de transformation. Trop d’organisations conçoivent encore des référentiels théoriques en chambre, sans ancrage opérationnel. 

La méthode AS IS / TO BE évite ce piège en partant directement du réel. Elle garantit de mener le projet à terme en respectant les objectifs de qualité, coûts et délais, en clarifiant l’existant pour définir et atteindre un état cible. Son principe : cartographier l’existant (AS IS), définir la cible (TO BE), puis mener une analyse des écarts pour tracer la trajectoire d’amélioration. 

Son enjeu est stratégique : mener une modélisation des processus réaliste pour atteindre les objectifs, embarquer les équipes terrain et prioriser les actions. Sans cet état des lieux, la transformation risque de s’essouffler et de faire face aux résistances du quotidien. 

Découvrez les tendances et pratiques des professionnels de la Qualité

AS IS / TO BE : définition de la méthode

Que signifient AS IS (existant) et TO BE (cible) ?

Le AS IS représente le processus tel qu’il fonctionne réellement aujourd’hui, avec ses forces et ses dysfonctionnements. Le TO BE décrit le processus cible à atteindre pour répondre aux enjeux stratégiques de l’organisation. La méthode AS IS / TO BE désigne l’approche structurée qui permet de passer du premier au second via l’analyse des écarts. 

💡 À noter : Le AS IS ne correspond pas à ce qui est écrit dans les processus non à jour, mais à la pratique quotidienne des équipes. De son côté, le TO BE n’est pas un processus utopique, mais une cible réaliste et mesurable. 

À quoi sert la méthode dans une démarche BPM / de transformation ?

La méthode AS IS / TO BE sert d’outil de cadrage d’une démarche BPM ou de transformation : elle sécurise les objectifs qualité-coûts-délais en ancrant le projet dans le réel. Elle permet d’éviter de modéliser des processus et créer des procédures théoriquement idéales mais qui constitueront un référentiel qui ne sera compris et appliqué par personne. 

Le piège majeur de la modélisation des processus est de créer des processus théoriquement parfaits, mais déconnectés avec le quotidien des opérationnels. Avec l’approche AS IS TO BE, vous sécuriser les engagements du projet : 

  • Qualité : Suppression des erreurs récurrentes et clarification des responsabilités
  • Coûts : Élimination des tâches à faibles valeur ajoutée et des doublons
  • Délais : Suppression des goulots d’étranglement

La méthode AS IS / TO BE agit comme un pont entre stratégie et exécution opérationnelle. 

Quand utiliser la méthode AS IS / TO BE ?

Vous pouvez appliquer la méthode AS IS / TO BE dès qu’un changement opérationnel ou technique nécessite de comprendre l’existant avant de construire autre chose. On peut notamment l’utiliser dans les projets suivants : 

  • Documentation et structuration des processus : mettre à plat le fonctionnement interne pour préparer une certification ou uniformiser les pratiques entre plusieurs sites
  • Refonte du SI et déploiement de nouveaux outils (ERP, CRM, GED) : Éviter d’implanter un nouveau logiciel sur un processus obsolète ou dysfonctionnel 
  • Projets de réorganisation interne, fusions / acquisitions : Harmoniser des cultures opérationnelles différentes en identifiant les meilleures pratiques de chaque entité
  • Démarche d’amélioration continue : Chasser le gaspillage (Muda) et fluidifier le parcours client

Étape 1 – Cartographier l’existant : le processus AS IS 

Pourquoi toujours commencer par l’AS IS ?

Vouloir modéliser le processus cible sans avoir cartographié l’existant est une perte de temps. Et pourtant, c’est l’une des erreurs les plus fréquentes en conduite du changement : imaginer une organisation idéale sans prendre en compte le quotidien des équipes. 

Sans connaissance du AS IS, il est impossible de : 

  • Mesurer la marche à franchir : comment évaluer l’effort de transformation si l’on ne sait pas d’où l’on part ? 
  • Identifier les causes racines : Corriger une anomalie visible sans analyser la chaîne de valeur amont conduit à déployer des solutions inefficaces ou temporaires.
  • Prioriser les actions à fort impact : sans état des lieux précis, on priorise au ressenti et non à la réalité terrain

Ainsi, le diagnostic AS IS permet d’objectiver la situation, d’être d’accord sur les dysfonctionnements constatés et de légitimer les actions d’amélioration à venir. 

Collecter le réel : interviews terrain, observation, données 

Lors de cette étape, le risque est de modéliser la procédure officielle plutôt que l’activité réelle. C’est pourquoi, construire le AS IS impose d’aller sur le terrain. 

Qui interviewer ? 

Vous devez interroger en priorité les opérationnels du quotidien (techniciens, gestionnaires, opérateurs), et pas uniquement les managers. Ce sont eux qui connaissent le mieux les dysfonctionnements terrain et qui connaissent réellement les règles d’exécution. 

Que faut-il capter lors des échanges ? 

La cartographie AS IS ne doit pas se limiter à une suite d’actions. Elle doit faire émerger : 

  • les activités réelles : ce qui est réalisé, étape par étape, y compris les tâches “invisibles”
  • les contournements : les documents annexes, les doubles saisies ou les validations par e-mail créés pour compenser les rigidités des outils informatiques. 
  • les irritants et points de friction : Les lourdeurs qui freinent les équipes, génèrent de la frustration et augmentent le risque d’erreur. 
  • les données d’activité : les volumes traités, les délais d’exécution et les temps morts lors des passages entre services. 

Comment objectiver la collecte ?

Croiser les entretiens individuels et les ateliers correctifs avec de l’observation directe sur le terrain et l’analyse de données factuelles (extraits ERP, tickets support…). Cela permet de distinguer ce qui relève de l’impression subjective de ce qui constitue une réalité. 

Modéliser simplement : choisir une notation lisible par tous (BPMN, Qualigram, logigramme)

Une fois toutes les informations collectées, dans un projet de transformation et d’optimisation des organisations, le modèle graphique doit être compris de tous.  le choix du langage graphique dépend de votre maturité organisationnelle et de vos objectifs : 

  • le logigramme classique : simple et intuitif, il utilise des formes basiques (rectangles, losanges) pour représenter les processus. Idéal pour une première initiation à la cartographie, il montre rapidement ses limites dès qu’il s’agit de gérer des processus complexes avec des interactions entre services. 
  • le BPMN : standard de modélisation des processus le plus connu, mais il n’est pas le seul et répond à des besoins spécifiques. De par ces spécificités, cet outil s’adresse particulièrement aux profils techniques (ingénieurs, experts réseaux…).  
  • Qualigram : langage graphique commun décrivant de manière spécifique les savoir-faire, à tous les niveaux de l’entreprise. Il est reconnu pour sa richesse fonctionnelle, sa simplicité d’utilisation et sa méthodologie intuitive. 

Pour aller plus loin sur le choix des représentations et les bonnes pratiques de modélisation, consultez notre article complet sur la cartographie des processus

Étape 2 – Définir l’état cible : le processus TO BE

Construire la cible en ateliers : qui impliquer et comment ?

La réussite du processus cible repose sur une co-construction avec les collaborateurs qui exécutent le travail au quotidien ainsi que le pilote du processus. 

L’atelier prend appui sur ce qui existe déjà, c’est-à-dire la cartographie de l’existant réalisée en étape 1. L’enjeu est de relever chaque irritant pour construire le processus cible idéal. Durant l’atelier, animez les échanges en questionnant la pertinence des étapes existantes (ex : Ce délais peut-il être réduit ? Cette donnée peut-elle être saisie plus tôt dans la chaîne ?). 

Le fait d’organiser de tels ateliers garantit l’adhésion des équipes au futur référentiel. Elles ne subissent pas des procédures imposées, mais contribuent à ces dernières en apportant leur vision terrain. 

Les critères d’un bon TO BE : valeur client, simplicité, faisabilité

Un processus TO BE se mesure à sa capacité à être appliqué sur le terrain. Pour valider l’état cible avant sa mise en œuvre, il faut passer chaque activité et leur donner des critères de conception plutôt que des généralités. Ainsi, chaque activité de la cible doit : 

  • Créer de la valeur : chaque action gardée dans le processus cible doit apporter une valeur directe au client (externe ou interne) ou répondre à une conformité. Tout activité qui ne répond pas à l’un de ses critères doit être simplifiée ou supprimée. 
  • Rester simple : le processus cible doit réduire le nombre d’intermédiaires, supprimer les contrôles inutiles et fluidifier le partage des informations entre les services. 
  • Être réalisable avec les moyens disponibles : la cible doit être atteignable avec les moyens humains, financiers et techniques disponibles. Si le processus idéal nécessite un développement logiciel lourd sur plusieurs années par exemple, il est préférable de définir un TO BE intermédiaire à court terme. 

Chasser les gaspillages et automatiser à bon escient 

Lorsqu’on définit le TO BE, on s’appuie directement sur les principes du Lean Management : identifier et supprimer les tâches sans valeur ajoutée pour concentrer l’effort sur l’efficience opérationnelle. 

Éliminer les gaspillages (Muda)

Lorsqu’on parle de gaspillage, on parle notamment de : 

  • temps d’attente (délais de validation, dossiers bloqués dans des boites mails génériques…)
  • les surtraitements et doublons (validations hiérarchiques redondantes, saisie manuelle d’informations déjà présentes dans un autre logiciel)
  • les non-conformités (erreurs de saisie en amont nécessitant des corrections ultérieures)

Pour vous aider à améliorer vos processus et donc votre organisation, nous avons réalisé un livre blanc téléchargeable gratuitement : Le Grand Guide de l’Amélioration continue. 

Automatiser uniquement un processus assaini 

L’automatisation via un ERP, un CRM ou des workflows est un super accélérateur de performance, à une condition : on n’automatise jamais un processus inefficient. Informatiser une organisation défaillante ne fait qu’augmenter la production d’erreurs. 

Étape 3 –  L’analyse des écarts (gap analysis) et le plan de transformation

Mesure l’écart AS IS / TO BE : la gap analysis

Si vous ne mesurez pas l’écart entre la cartographie existante et la modélisation de la cible, ces deux éléments resteront deux exercices déconnectés. Or, ce n’est pas ce que l’on souhaite. La gap analysis sert à comparer point par point la situation réelle et la situation visée afin de définir la marche à franchir. 

Pour mener à bien votre analyse d’écart, vous pouvez catégoriser les manques selon leur nature : 

  • Écarts d’activités et d’organisation : les tâches redondantes à éliminer, les nouvelles étapes de contrôle à intégrer ou la redéfinition des responsabilités au sein des équipes. 
  • Écarts de compétences : les besoins de formation ou d’accompagnement identifiés lorsque le processus cible demande de nouveaux savoir-faire.
  • Écarts d’outils : des évolutions applicatives nécessaires, les interfaces entre logiciels ou le développement de nouvelles fonctionnalités dans votre SI
  • Écarts de données et d’information : les données manquantes en entrée de processus, les formats non standardisés ou les ruptures dans la transmission de l’information entre deux services

Dans la mesure du possible, chaque écart doit être chiffré. Qu’il s’agisse de mesurer un gain de temps de cycle (en heures ou en jours), une économie financière ou une baisse du taux d’erreur, la quantification donne du poids à votre diagnostic et crédibilise la démarche auprès de la direction. 

Prioriser : impacts, efforts, risques (matrice de priorisation)

Tous les écarts identifiés ne peuvent pas être traités simultanément. Tenter de tout transformer en même temps est le meilleur moyen d’épuiser les ressources et de figer l’organisation. Pour arbitrer cela, vous pouvez vous appuyer sur une matrice de priorisation avec deux facteurs déterminants : impact métier (gains apportés par le TO BE) et l’effort de mise en œuvre (coût, temps, complexité technique et résistance au changement). 

Catégorie d’écartImpact métier / GainsEffort de mise en œuvreAction recommandéeExemple concret
Gains rapidesFortFaibleDéployer immédiatementSuppression d’une double validation hiérarchique inutile sur des montants mineurs.
Projets majeursFortFortPlanifier au schéma directeurDéploiement d’un portail client automatisé intégrant l’ERP.
SecondairesFaibleFaibleTraiter en second tempsHarmonisation des trames de compte-rendu entre deux entités.

Outre l’effort et l’impact, la qualification du risque est importante. Un écart qui met en péril la conformité réglementaire ou la sécurité doit être priorisé, même si son effort de déploiement est élevé. 

Du diagnostic au plan d’action : jalons, responsables et indicateurs 

Une fois l’analyse des écarts réalisée et priorisée, il faut transformer tout cela en plan d’action. Chaque écart conservé devient un projet d’amélioration doté d’un calendrier précis, de jalons clés et d’un responsable désigné. 

La réussite de ce plan repose sur sa dimension humaine. On peut en effet traiter des écarts d’outils ou d’organisation ce qui implique de faire évoluer les habitudes de travail. Pour accompagner ces changements, nous vous recommandons fortement de mettre en place une conduite du changement, en réalisant par exemple une analyse OMOC. 

Enfin, au fur et à mesure de l’avancement du projet, le référentiel doit être mis à jour progressivement. Le modèle TO BE actuel devient donc le nouveau AS IS de l’entreprise, plaçant l’organisation dans une démarche d’amélioration continue. 

Bonnes pratiques et erreurs à éviter avec l’AS IS / TO BE

Les pièges : AS IS trop détaillé, TO BE idéalisé, écart jamais piloté

Dans la mise en place de la méthode AS IS / TO BE, trois dérives méthodologiques reviennent fréquemment et peuvent avoir un impact négatif sur votre projet de transformation. 

1) L’AS IS qui devient une fin en soi

Le problème : Passer des mois à modéliser le moindre détail de l’existant, au risque de dépenser une énergie considérable pour documenter des dysfonctionnements déjà connus. 

La parade : Limiter l’effort de cartographie au strict nécessaire pour décider. Le AS IS n’est pas une encyclopédie, mais un outil d’arbitrage. Dès que les irritants majeurs et la structure sont stabilisés, passez à l’étape suivante.

2) Le TO BE idéalisé et conçu en chambre

Le problème : Modéliser une cible qui semble parfaite depuis le côté managériale, mais qui n’a pas été confrontée au terrain. Le risque est donc d’aboutir à un référentiel que personne n’appliquera.

La parade : Mener des ateliers de co-construction avec les opérationnels. Un processus cible légèrement moins ambitieux mais adopté par toutes les équipes terrain aura toujours plus de valeur qu’un modèle parfait sur le papier mais non appliqué au quotidien. 

L’analyse des écarts sans pilotage opérationnel

Le problème : Réaliser un très bon diagnostic AS IS / TO BE, puis mettre le plan d’action de côté faute de suivi et de gouvernance.

La parade : Instaurer une revue régulière des écarts restants lors des revues de processus. L’analyse des écarts peut être mise à l’ordre du jour permanent de l’amélioration continue. 

Le bon niveau de granularité et le bon rythme (itérer plutôt que tout figer)

Pour mettre en place une démarche BPM efficace, 3 niveaux de détail suffisent : 

  • Les processus : La vue d’ensemble de la chaîne de valeur et des interactions entre métier
  • Les procédures : la manière d’accomplir une activité ou un processus (Qui fait quoi, quand et avec quels documents et moyens ?)
  • Les instructions de travail : la description précise de la tâche d’un poste de travail

Au-delà de cette granularité, le rythme de déploiement conditionne la réussite du projet. Nous vous conseillons de suivre une approche itérative par périmètre plutôt que de vouloir cartographier toute l’entreprise avant d’agir. Traiter un premier processus de A à Z (AS IS → Gap analysis → TO BE → Plan d’action) permet de montrer l’intérêt de la méthode en quelques semaines et de créer une dynamique positive au sein de l’organisation. 

Outiller la démarche : faire vivre son référentiel dans le temps

Utiliser des outils d’illustration basiques ou des fichiers bureautiques isolés pour gérer une démarche AS IS / TO BE peut très vite montrer ses limites. Sans outil adapté, la gestion du versionning devient compliqué, la documentation n’est pas maintenue à jour et les collaborateurs perdent le fil des mises à jour. 

Pour garantir la pérennité de votre démarche, vous avez besoin d’un référentiel vivant capable de : 

  • gérer le versionning : conserver vos historiques de modèles (AS IS) tout en publiant la version TO BE 
  • diffuser aux équipes : offrir un accès partagé aux procédures actualisées pour l’ensemble des collaborateurs
  • maintenir en continu : permettre aux équipes terrain de remonter directement les écarts constatés entre la théorie et ce qui se passe sur le terrain

C’est d’ailleurs pour répondre à ces besoins que PYX4 Process, notre outil de cartographie des processus a été pensé. 

FAQ : questions fréquentes sur la méthode AS IS / TO BE 

Que veut dire AS IS / TO BE en français ?

En français, AS IS se traduit par « ce qui est » (l’état actuel ou la situation réelle) et TO BE par « ce qui doit être » (l’état cible visé). Dans une démarche processus, la méthode AS IS TO BE désigne la stratégie qui consiste à dresser l’état des lieux processus existant pour concevoir ensuite l’organisation future optimisée. 

Quelle différence entre gap analysis et analyse des écarts ?

Il n’y a aucune différence : Gap analysis est tout simplement le terme anglophone pour désigner l’analyse des écarts. Dans un projet de transformation, cette étape consiste à comparer le modèle existant (AS IS) et la cible visée (TO BE) afin d’identifier les écarts (risques, doublons, goulots d’étranglement). 

Faut-il toujours modéliser l’AS IS avant le TO BE ?

Oui, dans 95 % des projets de transformation, commencer par le AS IS est indispensable pour ancrer la démarche dans le réel et éviter la conception de référentiels théoriques. La seule exception concerne la création “à partir de rien” d’une activité entièrement nouvelle ou d’une start-up : en l’absence de fonctionnement préalable, on modélise directement le TO BE.

Quels outils utiliser pour cartographier AS IS et TO BE ?

Pour réussir la transition du AS IS au TO BE, la modélisation s’appuie sur plusieurs outils complémentaires :

  • Le SIPOC (ou FIPEC) pour cadrer le périmètre macro du processus en identifiant les entrées et sorties.
  • La matrice RACI pour clarifier les rôles et responsabilités (Qui fait quoi ? Qui valide ?)
  • Un logiciel BPM dédié pour formaliser et faire vivre le référentiel

La méthode AS IS TO BE est un levier redoutable pour réussir votre transformation : elle part d’un état des lieux processus incontestable (AS IS), co-construit un modèle cible réaliste (TO BE) et comble l’écart grâce à une analyse des écarts (gap analysis) méthodique. En évitant les pièges de la sur-documentation et du travail conçu en chambre, cette démarche garantit un référentiel vivant, pleinement adopté par le terrain car façonné avec lui.

Au lieu de piloter l’optimisation des processus à l’intuition, vous appuyez vos décisions sur des données factuelles et un plan d’action priorisé.

Passez à l’action : choisissez un processus clé, cartographiez son AS IS avec les équipes et identifiez les 5 écarts prioritaires vers votre cible.

Pour simplifier la modélisation des processus et faire vivre votre référentiel au quotidien, découvrez comment la suite PYX4 sécurise chaque étape de votre projet.

À lire aussi...

PYX4 - Rédaction de procédure Méthode en 7 étapes

Rédaction de procédure : méthode en 7 étapes, contenu type, exemples et modèle

Lorsqu’un collaborateur part, il emporte avec lui son savoir-faire, si ce dernier n’a jamais été formalisé. C’est le risque majeur de la non-formalisation : perte ...
PYX4 - Process et processus définitions, différences et bon usage

Les 3 types de processus : management, réalisation et support (définitions, exemples, méthode)

Les trois types de processus d’une organisation sont les processus de management (qui fixent le cap), les processus de réalisation (qui servent le client final) ...
PYX4 - Process et processus définitions, différences et bon usage

Process et processus : définitions, différences et bon usage

“On va revoir le process onboarding” : cette phrase, entendue dans de nombreuses organisations, masque une confusion qui peut coûter cher. Si cet emploi peut ...
PYX4 - Comment les logiciels BPM modernisent les soins de santé

Comment les logiciels BPM modernisent les soins de santé ?

Face à la saturation des hôpitaux et à la complexité administrative, le secteur de la santé doit se réinventer : sans cartographie claire des processus, ...