Quand le processus ne suffit plus
Tout chef de projet connaît cette situation: un dossier arrive, les étapes habituelles ne s’appliquent pas vraiment, et personne ne sait exactement dans quel ordre procéder, qu’il s’agisse d’un sinistre complexe en assurance, d’une plainte client atypique ou d’un audit aux ramifications multiples. Le réflexe naturel est de chercher une procédure existante, mais il n’y en a pas, parce que chaque cas de ce type est différent.
C’est précisément là qu’intervient le case management (gestion de cas): une approche de gestion conçue pour les situations où le travail ne peut pas être réduit à une séquence prédéfinie d’étapes. Contrairement aux processus structurés modélisés en BPMN (Business Process Model and Notation), où chaque tâche suit la précédente dans un ordre fixe, le case management part du principe que l’ordre des actions dépend du contexte, des informations disponibles et du jugement des acteurs impliqués.
Un dossier plutôt qu’un flux
La différence fondamentale tient à l’unité de travail. Dans un processus classique, on suit un flux: réception, vérification, validation, exécution, clôture. Chaque étape déclenche la suivante. Dans le case management, l’unité centrale est le dossier de cas (case file), c’est-à-dire l’ensemble des informations, documents et données associés à une situation donnée.
Ce dossier reste ouvert tant que le résultat visé n’est pas atteint. Les acteurs y ajoutent des éléments au fur et à mesure: rapports d’expertise, retours terrain, décisions intermédiaires. Les tâches disponibles évoluent en fonction de ce que contient le dossier et de l’état d’avancement global. Le parcours n’est pas tracé d’avance, il se construit au fil du traitement.
Un exemple illustre la distinction: lorsqu’un assureur reçoit une déclaration de sinistre pour un bris de vitre standard, le processus est clair et répétable. Mais pour un dégât des eaux touchant plusieurs parties, impliquant des experts, des sous-traitants et des questions de responsabilité, le traitement ne suit pas un chemin unique. L’ajusteur décide quelles actions engager en fonction des informations qui émergent progressivement: il peut demander une expertise complémentaire, solliciter un avis juridique ou négocier directement avec les parties concernées. C’est du case management, même si personne ne le nomme ainsi.
Les concepts qui structurent un cas
Le case management repose sur quelques concepts simples qui, une fois identifiés, aident à organiser le travail de manière plus explicite.
Les tâches discrétionnaires sont des actions que l’acteur responsable peut décider de lancer ou non selon le contexte. Elles ne sont pas imposées par le flux, elles sont rendues disponibles par l’état du dossier. Dans notre exemple d’assurance, commander une contre-expertise est une tâche discrétionnaire: elle n’a de sens que si les premiers résultats sont contestés ou insuffisants pour prendre une décision.
Les jalons (milestones) marquent des points de contrôle dans le traitement du cas. Ils indiquent qu’un certain état a été atteint, sans pour autant déclencher automatiquement l’étape suivante. “Toutes les pièces justificatives reçues” est un jalon. Il ne déclenche rien en soi, mais il rend possible certaines décisions, comme l’évaluation finale du montant.
Les critères d’entrée (sentries dans la terminologie technique) définissent les conditions sous lesquelles une tâche devient disponible ou un jalon est considéré comme atteint. Ces critères peuvent combiner des événements (“le rapport d’expert est arrivé”) et des conditions sur le dossier (“le montant estimé dépasse un seuil”). Cette mécanique rend le travail réactif aux informations plutôt qu’à un calendrier prédéfini.
Le chef de projet face au cas
Beaucoup de chefs de projet gèrent déjà des cas sans le savoir. Un projet de transformation organisationnelle qui avance par investigations successives, une gestion de crise où les actions se décident au jour le jour, un programme d’audit dont le périmètre évolue en fonction des découvertes: toutes ces situations relèvent davantage du case management que du processus structuré.
Reconnaître cette distinction a des conséquences pratiques. La première est de cesser de forcer un cadre séquentiel sur un travail qui ne l’est pas. Planifier un projet d’investigation en cascade, avec des livrables fixes à dates fixes, revient à prétendre connaître les réponses avant d’avoir posé les questions. Le case management invite à définir plutôt les actions possibles, les conditions de déclenchement et les jalons à atteindre, en laissant les acteurs décider du chemin en fonction des éléments dont ils disposent.
La deuxième conséquence concerne la documentation et le suivi. Dans un processus structuré, on sait où on en est parce qu’on connaît l’étape en cours dans le flux. Dans un cas, le suivi passe par le dossier: l’état d’avancement se lit dans les informations accumulées et les jalons franchis. Les outils de suivi doivent s’adapter en conséquence, en rendant visible l’état du dossier plutôt que la position dans un diagramme de flux.
La troisième conséquence touche à la gouvernance. Dans un processus structuré, les règles d’escalade et de validation sont intégrées au flux. Dans un cas, elles doivent être définies autrement: par des seuils de décision liés au contenu du dossier, par des revues périodiques, ou par des jalons qui déclenchent un point de contrôle avec la hiérarchie.
CMMN: la norme sous-jacente
Pour les organisations qui souhaitent formaliser leurs pratiques de case management, il existe une norme de modélisation dédiée: le CMMN (Case Management Model and Notation), publiée par l’OMG (Object Management Group) en 2014 et mise à jour en version 1.1 en 2016. Le CMMN fournit un langage graphique pour représenter les cas, les tâches discrétionnaires, les jalons et les critères d’entrée, de façon complémentaire à BPMN qui couvre les processus structurés.
En pratique, peu de chefs de projet généralistes auront besoin de maîtriser la notation CMMN. Son utilité principale réside dans le fait qu’elle donne un vocabulaire commun et une structure formelle à des pratiques qui restent souvent implicites. Savoir qu’une norme existe permet aussi de dialoguer plus efficacement avec les équipes SI lorsqu’il s’agit d’outiller la gestion de cas dans l’organisation.
Ce que le case management ne fait pas
Le case management n’est pas un substitut aux processus structurés. Pour les opérations répétables et bien définies (traitement d’une commande, onboarding d’un collaborateur avec une checklist fixe, approbation budgétaire standard), le BPM (Business Process Management) classique reste la bonne approche. Tenter d’appliquer une logique de cas à un processus qui fonctionne parfaitement en séquentiel ajoute de la complexité sans valeur ajoutée.
L’intérêt du case management apparaît précisément quand le processus structuré atteint ses limites: quand les exceptions deviennent plus fréquentes que la règle, quand le chemin dépend d’informations encore inconnues, ou quand le jugement humain est indispensable à chaque étape. Des plateformes comme Pega, IBM Case Manager ou ServiceNow intègrent aujourd’hui les deux logiques, permettant de basculer entre flux structuré et dossier ouvert au sein d’un même environnement. Cette coexistence outillée reflète une réalité que les chefs de projet connaissent bien: la plupart des programmes combinent des volets parfaitement répétables et des volets dont le déroulement se découvre en avançant.