Créer des flux d’approbation : une demande de congé qui remonte par e-mail au manager, qui la transfère au RH, qui relance trois jours plus tard parce que rien n’a été validé formellement : les circuits de validation informels sont l’un des plus grands gaspillages de temps dans la gestion de projet, et pourtant la plupart des organisations continuent à les gérer via des chaînes d’e-mails ou des documents papier scannés. L’application Approbations, intégrée nativement à Microsoft Teams, permet de construire des workflows de validation à plusieurs niveaux directement dans l’outil que vos équipes utilisent déjà, sans licence supplémentaire ni portail externe. Couplée à Power Automate pour les cas plus complexes, elle couvre aussi bien la validation d’une dépense, d’un livrable client, d’un changement de périmètre projet ou d’une demande d’accès. Voici comment la mettre en œuvre concrètement pour un circuit à plusieurs niveaux, avec les arbitrages qui font la différence entre un flux réellement adopté et un gadget abandonné après deux semaines.
Démarrer avec l’application Approbations native
L’application Approbations, accessible depuis la barre latérale de Teams (parfois à ajouter via les trois points « Plus d’applications »), permet de créer une demande simple en quelques champs : titre, détails, approbateurs, pièces jointes, et surtout un choix entre approbation « en série » ou « en parallèle ». Pour un flux multi-niveaux basique — par exemple une validation de note de frais qui doit passer par le manager direct puis par le contrôle de gestion — le mode série suffit : chaque approbateur reçoit la demande seulement après validation du précédent, avec un historique complet conservé dans l’onglet Approbations. Cette version native convient parfaitement aux besoins ponctuels et aux petites équipes, sans nécessiter de compétences techniques. Sa limite apparaît vite dès que le circuit doit s’adapter dynamiquement : un montant au-dessus d’un seuil qui ajoute un niveau supplémentaire, une approbation qui doit déclencher une action dans un autre système, ou un rappel automatique après quarante-huit heures sans réponse. Pour ces besoins, il faut basculer vers Power Automate, qui prend le relais avec la même interface de validation dans Teams mais une logique de circuit bien plus riche en coulisses.
Construire un circuit conditionnel avec Power Automate
Power Automate propose un connecteur Approbations dédié, avec une action « Démarrer une approbation » et un modèle prêt à l’emploi pour les circuits multi-niveaux. La logique la plus robuste pour un flux à plusieurs niveaux conditionnels repose sur une branche de décision en amont : le flux vérifie d’abord une variable (montant, criticité, type de demande) issue d’un formulaire Microsoft Forms ou d’une liste Microsoft, puis oriente la demande vers un, deux ou trois approbateurs successifs selon le résultat. Un cas concret et fréquent en gestion de projet : une demande de changement de périmètre (change request) en dessous de cinq mille euros ne nécessite que la validation du chef de projet ; entre cinq et vingt mille euros, elle ajoute le sponsor ; au-delà, elle remonte au comité de pilotage via une approbation collective où l’unanimité ou la majorité peut être exigée selon le paramétrage de l’action « Démarrer et attendre une approbation » en mode « Tous doivent approuver » ou « Le premier qui répond ». Chaque étape écrit son résultat dans une liste Microsoft ou un fichier Excel structuré, ce qui donne une traçabilité complète et interrogeable, contrairement à une chaîne d’e-mails où retrouver l’historique d’une décision prend un temps disproportionné.
Cas d’usage concrets pour la gestion de projet
Trois circuits reviennent systématiquement dans un contexte de gestion de projet et méritent d’être industrialisés dès le démarrage. Le premier concerne la validation des livrables : un document déposé dans la bibliothèque SharePoint du canal « Livrables » déclenche automatiquement, via un flux Power Automate surveillant le dossier, une demande d’approbation adressée au responsable qualité puis au client interne, avec le fichier en pièce jointe directement consultable dans la carte de validation Teams, sans quitter l’application. Le deuxième concerne les demandes de changement (change requests), décrites plus haut, où la traçabilité est un enjeu de gouvernance autant que d’efficacité. Le troisième, souvent sous-estimé, concerne les demandes d’accès aux ressources projet : ajout d’un prestataire externe à l’équipe Teams, ouverture d’un accès à un environnement sensible, ou extension d’une licence — un flux d’approbation impliquant le chef de projet puis le RSSI garantit que ces accès ne sont jamais accordés sur simple demande verbale, un point régulièrement soulevé lors des audits de sécurité. Dans chacun de ces cas, la carte adaptative affichée dans Teams permet d’approuver ou de rejeter en un clic, avec un champ de commentaire obligatoire en cas de rejet, ce qui évite les refus non motivés qui bloquent la suite du processus sans explication exploitable.
Gérer les délégations, relances et exceptions
Un circuit d’approbation qui ne prévoit pas l’absence de l’approbateur finit toujours par bloquer un projet au pire moment. Power Automate permet d’ajouter une action de relance automatique après un délai défini (par exemple vingt-quatre ou quarante-huit heures sans réponse), avec un message dans le canal Teams concerné plutôt qu’un simple e-mail, pour rester dans le fil de discussion naturel de l’équipe. Pour la délégation, deux approches coexistent : la délégation native de Teams et Outlook, qui permet à un approbateur d’assigner temporairement ses approbations à un remplaçant pendant ses congés, et une délégation gérée directement dans le flux, avec une liste de suppléants consultée automatiquement si le premier approbateur n’a pas répondu après le délai de relance. Cette seconde option, plus robuste, évite de dépendre du bon réglage individuel de chaque approbateur avant son départ en congé. Prévoyez également un mécanisme d’escalade automatique : si une demande reste sans réponse après un délai maximal (typiquement cinq jours ouvrés), le flux doit notifier automatiquement le niveau supérieur plutôt que de rester bloquée indéfiniment dans la boîte de réception de quelqu’un qui n’a pas vu la notification.
Pièges à éviter dans la conception du circuit
Le piège le plus courant consiste à copier fidèlement dans Power Automate un circuit papier hérité, avec ses sept niveaux de validation historiques, sans profiter de l’occasion pour le simplifier. Un flux numérique qui reproduit une lourdeur administrative obsolète n’apporte aucun gain, il ne fait que numériser la lenteur. Profitez de la mise en place du workflow pour challenger chaque niveau : est-il réellement nécessaire, ou hérité d’une époque où la traçabilité papier justifiait des doubles validations ? Le deuxième piège est l’absence de test de charge : un flux conçu et validé avec cinq demandes de test peut se comporter différemment avec cinquante demandes simultanées, notamment si le connecteur SharePoint ou la liste Microsoft utilisée en arrière-plan atteint ses limites de requêtes API. Le troisième piège, plus organisationnel, est de ne pas former les approbateurs à l’usage de la carte Teams : certains continuent à répondre par e-mail au message de notification plutôt que de cliquer sur « Approuver » dans la carte, ce qui casse la traçabilité et oblige à une relance manuelle. Un court mode d’emploi d’une page, partagé au démarrage du flux, suffit généralement à éviter ce problème.
Un flux d’approbation multi-niveaux bien conçu dans Teams ne se contente pas de remplacer une signature papier par un clic : il rend visible et mesurable un processus qui, sous sa forme informelle, restait opaque et source de retards silencieux. En démarrant avec l’application Approbations native pour les cas simples, en montant en puissance vers Power Automate pour les circuits conditionnels, et en soignant la gestion des délégations et des escalades, vous obtenez un système de gouvernance qui accélère les décisions au lieu de les ralentir, tout en produisant automatiquement l’historique que tout audit de projet finit par réclamer.