Au départ, la demande paraissait simple. Une structure souhaitait automatiser l'envoi d'un mail après réception d'un formulaire en ligne : le prospect recevait ensuite un lien vers une page de réservation pour choisir un créneau de visio, avec un système de relance si aucune réservation n'était faite. Sur le papier, le besoin semblait assez précis pour ouvrir Power Automate et commencer à construire le flux.
Je n'ai pourtant pas commencé par l'automatisation. Les premiers entretiens avec les deux personnes les plus directement impliquées dans le parcours client ont fait apparaître plusieurs différences de compréhension. Chacune connaissait son travail, mais une partie du fonctionnement reposait sur des habitudes, des échanges informels et des arbitrages pris au fil de l'eau. Le problème n'était donc pas de savoir comment envoyer un mail automatiquement. Il fallait d'abord comprendre dans quel processus ce mail allait intervenir.
Une demande d'automatisation ne décrit qu'une partie du besoin
Quand un responsable demande d'automatiser une relance, il décrit la partie la plus visible de son problème : le mail à envoyer, la relance qu'on risque d'oublier, le formulaire à recopier, le document à produire. Cette demande est légitime, elle part d'une friction réelle.
Mais elle ne dit pas nécessairement qui doit qualifier la demande reçue, dans quels cas l'envoi doit être différé, qui reprend le dossier après la visio, quelle information fait foi, où le résultat doit être enregistré, ni quelles exceptions réclament une décision humaine. Dans cette mission, le mail et la réservation n'étaient que quelques étapes d'un parcours beaucoup plus large, de la réception du formulaire jusqu'à l'accompagnement dans la durée. Automatiser la seule partie visible aurait réduit un irritant, sans rien régler du suivi du dossier dans son ensemble.
L'automatisation oblige à choisir une seule règle
Un processus manuel peut fonctionner longtemps avec des règles imprécises. Une personne expérimentée sait qu'il faut parfois attendre avant de répondre, reconnaît un dossier incomplet, sait à qui poser une question, se souvient qu'un cas particulier ne suit pas le circuit habituel.
Une automatisation ne dispose pas de cette connaissance. Il faut lui indiquer ce qui déclenche le traitement, les conditions pour continuer, les informations nécessaires, les actions à réaliser, les personnes à prévenir, les situations où le traitement doit s'arrêter, et la trace à conserver une fois l'action terminée. Tant que ces éléments ne sont pas explicites, celui qui construit le flux interprète le fonctionnement et finit par inscrire ses propres hypothèses dans l'automatisation.
Le risque n'est pas la panne spectaculaire : le flux peut fonctionner et produire exactement ce qu'on lui a demandé. Le problème, c'est que ce qu'on lui a demandé ne correspond pas toujours à ce que l'équipe doit réellement faire. C'est la même mécanique que celle décrite dans l'article sur l'IA qui ne compense pas une organisation désordonnée : un outil rapide donne l'impression que la vérification a déjà eu lieu, alors qu'elle n'a souvent pas commencé.
Quand le processus devient le premier livrable
Les entretiens de cadrage ont donc conduit à élargir temporairement le travail. Avant de construire la moindre automatisation, j'ai décrit le parcours existant puis proposé un modèle cible plus lisible, découpé en jalons. Ce travail a clarifié quatre dimensions.
Les étapes du parcours
Distinguer la réception de la demande, la préqualification, la prise de contact, la réservation de la visio, le diagnostic, la proposition, la contractualisation et l'accompagnement. Certaines démarches pouvaient être préparées en amont, d'autres seulement une fois la personne prise en charge, avec des conséquences directes sur les rappels à envoyer et les informations à demander.
Les responsabilités
Un flux peut envoyer une notification, il ne décide pas qui doit agir ensuite. Un RACI simplifié a précisé qui pilote le dossier, qui assure le suivi, qui décide, qui valide les documents engageants, qui met à jour l'information. Une règle simple a été retenue : la personne qui réalise une action met à jour l'action correspondante dans le système. Elle n'est pas technique, mais elle est ce qui garde à jour les données dont dépendent les automatisations.
Les espaces et les données
Le processus reposait sur des supports dispersés : documents Word, notes, messages, fichiers épars. Difficile d'automatiser durablement si le flux ne sait pas où lire le statut d'un dossier, où créer une action, où déposer un document, ni quelle source fait foi. Le modèle cible a séparé trois fonctions : une liste pour savoir où en est chaque dossier, une liste pour suivre les actions et leurs responsables, une bibliothèque pour conserver preuves et livrables. Cette distinction rejoint celle entre espace individuel et espace collectif, développée dans l'article sur OneDrive pour soi et SharePoint pour l'équipe.
Les exceptions
Un formulaire incomplet, un prospect qui ne réserve pas, une visio annulée, un arbitrage à rendre, un document manquant, une relance à suspendre. Traitées avant le développement, au moins pour les plus fréquentes, elles font partie de la conception. Traitées après coup, elles deviennent une accumulation de conditions difficiles à maintenir.
Clarifier ne veut pas dire tout modéliser pendant des mois
La réponse n'est pas de produire une documentation exhaustive avant la première automatisation. Un processus vivant comporte toujours des variantes, dont certaines n'apparaîtront qu'à l'usage. L'objectif est un niveau de clarté suffisant pour une première version fiable : le début et la fin du processus sont identifiés, les étapes principales partagées, les responsabilités acceptées, les données ont un emplacement connu, les décisions humaines sont conservées, les exceptions courantes prévues, et une trace permet de vérifier ce que le flux a fait.
Dans cette mission, cette logique a conduit à un socle volontairement simple, puis à déposer les premières automatisations dans une version MVP. Elle a donné satisfaction sans être présentée comme définitive : elle devait d'abord servir en conditions réelles, pour révéler les bugs, les ajustements et les tâches suivantes à automatiser. La montée de version en cours suit exactement cette logique, corriger ce que l'usage a montré puis étendre le périmètre.
Les sept questions à se poser avant d'ouvrir Power Automate
Avant de construire un flux, ce contrôle s'applique à n'importe quel processus réel de votre structure.
- Quel événement déclenche vraiment le processus ? La réception d'un formulaire, sa validation, ou une décision humaine prise après lecture ?
- Quelles informations sont indispensables ? Un mail, un nom et une date suffisent-ils, et que doit faire le flux si une donnée manque ou paraît incohérente ?
- Qui prend la décision suivante ? Le flux exécute-t-il une règle déjà tranchée, ou remplace-t-il un arbitrage jamais formalisé ?
- Où se trouve l'information de référence ? Dans une liste SharePoint, une boîte mail, ou dans la tête de la personne qui suit le dossier ?
- Qui devient responsable après l'action automatique ? Une notification sans responsable clairement identifié déplace le risque d'oubli, elle ne le supprime pas.
- Quelles exceptions doivent interrompre le flux ? Identifier les situations où l'automatisation doit s'arrêter, demander une validation ou remettre le dossier à une personne.
- Quelle preuve permettra de contrôler le résultat ? Un mail envoyé n'est pas toujours un processus terminé : il peut falloir enregistrer un statut, une échéance, une décision ou un lien vers un document.
Si plusieurs réponses restent incertaines, le processus mérite une séance de clarification avant le développement.
Automatiser vient après comprendre, pas après tout documenter
Une automatisation utile ne commence pas par un cahier des charges volumineux, mais par une compréhension partagée du travail réel. Ici, la demande initiale portait sur quelques mails et relances. Le cadrage a montré qu'une automatisation durable supposait aussi de clarifier le parcours, les responsabilités, les espaces et les règles de gestion des données. Ce détour n'a pas retardé le projet, il a permis de le construire sur un socle compréhensible et évolutif. La bonne question n'est pas seulement « que pouvons-nous automatiser ? », mais d'abord « sommes-nous assez d'accord sur ce qui doit se passer ? ».
Questions fréquentes
Faut-il modéliser tout le processus avant de créer un premier flux ?
Non. Il faut surtout clarifier le périmètre du flux : son déclencheur, ses règles principales, les responsabilités, les données nécessaires et les exceptions courantes. Le reste s'enrichit progressivement.
Comment savoir si un processus est assez clair pour être automatisé ?
Demandez à deux personnes impliquées de décrire séparément les étapes, les responsabilités et les cas particuliers. Si leurs réponses divergent sur des points déterminants, le processus doit encore être clarifié.
Peut-on automatiser un processus qui comporte des exceptions ?
Oui, à condition de ne pas chercher à tout automatiser. Certaines exceptions se redirigent vers une validation humaine ou créent une action à traiter manuellement.
Pourquoi commencer par un MVP ?
Une première version limitée permet de tester les règles avec de vrais dossiers, de détecter les anomalies et de vérifier l'appropriation par l'équipe avant de multiplier les automatisations.
Power Automate peut-il compenser un manque d'organisation ?
Il exécute une règle, transmet une information, crée une action. Il ne décide pas quelle règle est pertinente, quelle information fait foi, ni qui porte la responsabilité du traitement.
Vérifier si un processus est assez clair pour être automatisé, et repérer où placer le contrôle humain avant d'ouvrir le moindre outil — c'est justement l'objet du pré-diagnostic gratuit Econoria.