Créer un point d'accueil pour les demandes et requêtes internes avec Microsoft Forms — centraliser dans un formulaire les demandes reçues par e-mail et à l'oral

« Merci de créer un compte serveur » arrive par e-mail, « l’imprimante fonctionne mal, peux-tu regarder » se demande à l’oral en se croisant dans le couloir, « merci de traiter cette facture » est collé sur le bureau avec un post-it. Nous recevons souvent des consultations, de la part de services comme l’informatique, l’administration ou la comptabilité qui reçoivent des demandes internes, qui veulent remédier à cet état de fait.

Celui qui fait la demande pense « je l’ai dit, donc ce sera fait » ; celui qui la reçoit ne peut compter que sur sa mémoire et sa boîte mail. C’est justement les jours chargés qu’une demande passe à la trappe, et cela se découvre au moment où l’on entend « et cette affaire, où ça en est ? » Pour une entreprise ayant déjà adopté Microsoft 365, ce problème peut être largement résolu avec un « modèle d’accueil » qui fait de Microsoft Forms le point d’entrée et automatise la notification et l’enregistrement avec Power Automate. Cet article couvre la pratique de la conception de formulaire, les contraintes du téléversement de fichiers, la forme de base du flux d’accueil, et enfin les limites de Forms seul et la raison pour laquelle la transcription vers une liste devient la solution de référence. La conception de l’approbation et de la validation elles-mêmes est le sujet principal d’un autre article, « Créer un flux d’approbation avec Power Automate — numériser les circuits de validation et les demandes sur papier et par e-mail », donc cet article-ci se concentre sur « l’accueil ».

Public visé et environnement présupposé

• Public visé : les responsables côté informatique, administration, comptabilité, etc., qui reçoivent des demandes ou requêtes venant de l’interne. Cet article est écrit en présupposant que vous n’avez jamais touché à Power Automate.
• Environnement présupposé : avoir déjà adopté Microsoft 365, avec Microsoft Forms et SharePoint disponibles. La création de flux nécessite une licence permettant d’utiliser Power Automate, mais les connecteurs Forms, SharePoint, Outlook et Teams utilisés dans cet article relèvent tous des connecteurs standard — aucun connecteur premium n’intervient (pour la frontière, voir « Licences Power Automate et la frontière entre connecteurs standard et premium »).
• Droits nécessaires : être membre du groupe (équipe) où sera placé le formulaire, et pouvoir créer une liste sur le site SharePoint de destination de la transcription. Les droits d’administrateur du tenant ne sont pas nécessaires, mais la valeur par défaut de l’enregistrement du nom du répondant et la possibilité de partage externe sont déterminées par les paramètres d’administration.¹
• Ce que cet article vous fait construire : un formulaire d’accueil des demandes, une liste SharePoint servant de registre d’accueil, et un flux cloud qui se déclenche à la réception.

1. La conclusion, d’abord

• Le point d’accueil des demandes se conçoit en associant « un format de saisie » et « un emplacement d’enregistrement ». La configuration minimale réaliste est « recevoir avec Forms → transcrire vers une liste SharePoint via Power Automate → notifier ».
• La forme de base du flux tient en deux étapes : le déclencheur « Quand une nouvelle réponse est envoyée » et l’action « Obtenir les détails de la réponse ». Le connecteur Forms ne comporte que ce déclencheur et cette action (plus la récupération des détails du formulaire), il n’y a donc pas énormément à retenir.²³
• La diffusion doit, en principe, rester restreinte à l’organisation. En activant « enregistrer le nom », le nom et l’adresse e-mail du répondant sont enregistrés automatiquement, sans qu’il faille faire saisir le nom ni le service. Dans un réglage ouvert à l’extérieur de l’organisation, les réponses deviennent anonymes et rien n’indique qui les a envoyées.⁴
• La question de téléversement de fichier est réservée aux formulaires restreints à l’organisation. Une question accepte au maximum 10 fichiers, la limite par fichier se choisit parmi 10 Mo, 100 Mo ou 1 Go, et les fichiers sont enregistrés dans OneDrive for Business.⁵
• Le secret de la longévité consiste à considérer Forms comme dédié à l’accueil, un point c’est tout. Il n’y a aucune fonction de modification après envoi ni de suivi d’avancement, et la liste des réponses ne dispose pas non plus de mécanisme de gestion des statuts ; le registre doit donc résider côté liste SharePoint.⁶
• La limite du nombre de réponses atteint jusqu’à 5 000 000 pour un compte professionnel ou scolaire — quasi illimité pour un usage interne — mais au-delà de 50 000 réponses, le graphique de synthèse et la consultation des réponses individuelles deviennent indisponibles. C’est « la faiblesse de la gestion en liste » qui devient limitante avant le plafond de volume.⁷
• Un accueil venant de l’extérieur avec pièce jointe nécessaire, un volume important à relier au système central, un besoin de rendre l’avancement visible au demandeur — voilà où l’on commence à dépasser le terrain de Forms. La ligne de partage est résumée dans le tableau de décision du chapitre 7.

2. Ce qui pose problème dans les demandes reçues par e-mail et à l’oral

Le problème d’une pratique où l’on reçoit les demandes par e-mail et à l’oral réside dans une structure que les efforts individuels du responsable ne peuvent pas résoudre.

• Des oublis surviennent structurellement. Les demandes arrivent par des canaux séparés — boîte de réception, messagerie instantanée, oral, post-it — si bien qu’« une liste de la totalité des demandes » n’existe nulle part. On mise tout sur la mémoire d’une seule personne pour ne rien perdre.
• Le format n’est pas uniforme, ce qui multiplie les allers-retours. Un e-mail réduit à « merci de configurer le PC » ne précise ni le PC concerné, ni la date souhaitée, ni le motif, ce qui déclenche des allers-retours de clarification. Devoir se rappeler et écrire à chaque fois les informations nécessaires est aussi une charge pour celui qui demande.
• Le statut n’est pas visible, ce qui mène à des désaccords sur « qui a dit quoi ». Le demandeur ne voit pas si sa demande a été reçue, si elle est en cours, ni quand elle se terminera. Si le responsable répond « je n’en ai pas entendu parler », c’est parole contre parole. Les échanges de relance et de vérification eux-mêmes grignotent le temps des deux parties.
• Impossible d’établir des statistiques. Comme aucune donnée ne subsiste sur le nombre de demandes reçues par mois ni sur ce à quoi le temps est consacré, on ne peut pas étayer par des chiffres des affirmations comme « il manque du personnel » ou « ce système reçoit trop de demandes ».

Ces problèmes se résolvent globalement dès lors qu’on met en place un mécanisme où « le point d’entrée des demandes est unique, les informations nécessaires sont reçues sous un format standardisé, et l’enregistrement ainsi que la notification se déclenchent dès la réception ». La raison d’utiliser Forms et Power Automate, c’est que si Microsoft 365 est déjà adopté, ce mécanisme peut souvent être construit sans coût supplémentaire (les connecteurs Forms, SharePoint, Outlook et Teams utilisés dans cet article relèvent tous des connecteurs standard ; nous détaillons l’approche des licences dans « Licences Power Automate et la frontière entre connecteurs standard et premium »).

3. La pratique de la conception du formulaire

Le principe : « faire choisir » plutôt que « faire écrire »

L’objectif de la conception du formulaire, c’est que le demandeur puisse l’envoyer sans hésiter, et que le responsable dispose de toutes les informations pour agir sans avoir à demander de précisions. Le principe est « recevoir avec des choix, réduire le texte libre au minimum ».

• Le type de demande se règle en choix. Fixez avec des choix comme « création de compte / PC et périphériques / installation de logiciel / autre » un axe qui servira ensuite aux statistiques et aux branchements du flux.
• L’échéance se reçoit comme question de date. Cela élimine les flottements du type « dès que possible » ou « cette semaine », et permet aussi au flux de s’en servir pour des rappels (le traitement des jours ouvrés et des dates limites est couvert dans « Flux planifiés et logique des jours ouvrés dans Power Automate »).
• Concentrez le texte libre sur une seule question « complément d’information », en règle générale. Une remarque pratique s’impose ici : une saisie dépassant 255 caractères dans un texte sur une ligne (réponse courte) peut, c’est un problème connu, faire fonctionner le flux de façon intermittente. Pour toute question susceptible de recevoir un texte long, réglez-la d’emblée en « réponse longue » (texte multiligne).⁸

Et surtout, ne « faites pas trop écrire ». Le rôle d’un formulaire d’accueil, c’est de saisir la demande sans en perdre, pas de recueillir toute l’information sur-le-champ. Un formulaire à trop de questions renvoie vers l’oral ou l’e-mail. Pour les cas nécessitant un entretien détaillé, partez du principe que le responsable rappellera après réception, et gardez le formulaire à un grain que l’on peut remplir en quelques minutes.

Les branchements pour ne pas montrer des « questions sans rapport »

Quand ce qu’il faut demander diffère selon le type de demande, utilisez les branchements (branching). Ils permettent de changer les questions ou sections affichées ensuite en fonction de la réponse à un choix, de sorte que — par exemple, « système concerné et droits d’accès pour une création de compte, numéro d’inventaire et symptômes pour une panne de matériel » — le répondant ne voit que les questions qui le concernent. Les branchements ne peuvent sauter que vers des questions situées plus loin (impossible de revenir à une question antérieure), donc une configuration efficace place les questions communes en première partie, et les questions spécifiques à chaque type dans des sections en seconde partie.⁹

Diffusion et informations sur le répondant — la différence entre restriction à l’organisation et anonymat

Il existe 3 types de diffusion pour Forms.⁴

Le point d’accueil des demandes internes doit en principe rester restreint à l’organisation, pour trois raisons.

1. On évite de faire écrire « qui a envoyé la demande ». En activant « enregistrer le nom », le nom et l’adresse e-mail du répondant s’ajoutent automatiquement à la réponse. Cela permet de supprimer entièrement les questions « toujours les mêmes à chaque fois » — nom, service, coordonnées.⁴
2. Certaines fonctionnalités, comme la limite à une réponse par personne ou le téléversement de fichiers, ne sont disponibles que dans une diffusion restreinte à l’organisation. « Une réponse par personne » ne peut elle aussi être réglée que dans ce cas.⁴
3. Le flux peut répondre au demandeur. Comme les détails de la réponse contiennent l’adresse e-mail du répondant (Responders’ Email), on peut envoyer directement l’e-mail de confirmation d’accueil (chapitre 5). Un formulaire anonyme ne le permet pas.¹⁰

Notez que la question de savoir si le nom du répondant est enregistré par défaut au niveau de toute l’organisation est contrôlée par un administrateur dans les paramètres Forms du centre d’administration Microsoft 365 (« Enregistrer le nom par défaut »). L’autorisation du partage externe (demander des réponses hors de l’organisation) elle-même, au niveau du tenant, se règle sur le même écran. Si l’entreprise a une politique du type « les sondages internes sont anonymes par défaut », vérifiez-la également ici.¹

Récapitulons aussi ce que l’on perd si l’on doit malgré tout ouvrir le formulaire vers l’extérieur.

• Rien n’indique qui a envoyé. Les réponses à un formulaire ouvert hors de l’organisation deviennent anonymes, et le répondant peut envoyer sans se connecter.¹¹ Ni l’usurpation d’identité ni l’envoi en double ne peuvent être empêchés côté formulaire. La limite « une réponse par personne » n’étant disponible qu’en restriction à l’organisation, la même personne peut envoyer autant de fois qu’elle le souhaite.⁴
• Impossible de recevoir des pièces jointes. La question de téléversement de fichier est réservée aux formulaires restreints à l’organisation.⁵
• Le flux ne peut plus répondre au demandeur. L’adresse e-mail du répondant (Responders’ Email) n’étant pas disponible, le mécanisme le plus efficace — la réponse automatique d’e-mail de confirmation d’accueil — devient inutilisable (faire saisir l’adresse e-mail en texte libre expose directement à une adresse mal tapée devenant un e-mail qui n’arrive jamais).
• Ce n’est parfois même pas autorisé du tout. Le partage externe pouvant être interdit par les paramètres d’administration du tenant, il peut arriver que distribuer le lien ne permette à personne de répondre. Vérifiez au préalable auprès de votre administrateur.¹

Pour un usage externe, la zone sûre s’arrête à « un accueil de type sondage, avec peu de réponses, sans besoin de pièce jointe ni de vérification d’identité ». Au-delà, comme l’indique le tableau de décision du chapitre 7, il faut basculer vers une conception de formulaire web.

Ne pas laisser le formulaire au nom d’une seule personne — se préparer au départ de son créateur

C’est un point souvent négligé mais important. Un formulaire créé par un individu est lié à son compte, et si ce compte est supprimé du tenant, par exemple lors d’un départ, les données associées au compte sont effacées 30 jours après la suppression.¹¹ Comme un formulaire d’accueil est un point d’entrée de l’activité de l’entreprise, ne le laissez pas comme un bien personnel du responsable : créez-le comme formulaire d’un groupe (équipe), ou définissez à l’avance une procédure de transfert de propriété en cas de mutation ou de départ.⁸

Un point d’attention côté flux : un formulaire de groupe n’apparaît pas dans la liste des ID de formulaire du déclencheur Power Automate ; il faut copier la valeur après FormId= dans l’URL de l’écran d’édition du formulaire, et la saisir manuellement comme ID de formulaire.³ C’est un peu de travail en plus, mais la valeur d’éviter la dépendance à une seule personne le justifie largement.

4. Spécifications et contraintes du téléversement de fichiers

Les cas où une demande s’accompagne d’une pièce jointe — « demande d’achat avec le devis PDF joint », « signalement d’incident avec la capture d’écran de l’erreur jointe » — sont nombreux. Il faut connaître précisément les spécifications de la question de téléversement de fichier de Forms.⁵

• Réservée aux formulaires restreints à l’organisation. Elle ne peut être ajoutée que lorsque la diffusion est réglée sur « seuls les utilisateurs de mon organisation peuvent répondre » ou « des utilisateurs spécifiques de l’organisation peuvent répondre » ; elle est indisponible sur un formulaire ouvert hors de l’organisation. Autrement dit, Forms ne convient pas à un usage comme « faire déposer une demande avec pièce jointe par un partenaire externe ».
• Jusqu’à 10 fichiers par question, avec une limite de taille par fichier à choisir parmi 10 Mo, 100 Mo ou 1 Go.
• Possibilité de limiter le type de fichier. Vous pouvez choisir les types autorisés parmi Word, Excel, PowerPoint, PDF, image, vidéo, audio — permettant par exemple « le devis doit être un PDF uniquement ».
• L’emplacement d’enregistrement dépend du propriétaire du formulaire. Pour un formulaire personnel, les fichiers téléversés par les répondants s’accumulent dans le dossier « Applications > Microsoft Forms > (nom du formulaire) > (nom de la question) » du OneDrive for Business du créateur ; pour un formulaire de groupe, comme recommandé au chapitre 3, ils s’accumulent dans le site SharePoint du groupe.

Traiter les fichiers téléversés depuis le flux demande un peu de travail supplémentaire. La réponse à la question de téléversement, telle que retournée par « Obtenir les détails de la réponse », est une chaîne JSON contenant le nom de fichier et l’ID, il faut donc la décomposer avec « Analyser JSON (Parse JSON) » en fournissant un schéma, puis extraire l’ID de fichier avec une expression comme first(body('Parse_JSON'))?['id'] avant de le transmettre à l’action de récupération de fichier.¹⁰

Pour construire le schéma, la méthode officielle — le générer à partir d’un exemple réel — est la plus fiable. Trois étapes : ① enregistrez le flux et lancez une exécution de test, en téléversant un fichier depuis le formulaire → ② dans l’historique d’exécution, ouvrez « Obtenir les détails de la réponse » et copiez la sortie de cette question de téléversement → ③ collez-la dans « Générer à partir d’un exemple » de l’action « Analyser JSON ».¹⁰

Si vous préférez l’écrire à la main, une forme minimale ne déclarant que les propriétés utilisées suffit (l’analyse JSON réussit même si des propriétés non déclarées sont retournées). Comme seul l’ID de fichier est nécessaire pour créer un lien de partage, cela se limite en pratique à ceci.

{
    "type": "array",
    "items": {
        "type": "object",
        "properties": {
            "id":   { "type": "string" },
            "name": { "type": "string" }
        },
        "required": [ "id" ]
    }
}

Le point d’attention le plus important ici, c’est que la réponse est retournée sous forme de tableau. C’est pourquoi l’expression officielle prend la forme first(body('Parse_JSON'))?['id'], qui extrait le premier élément.¹⁰ Notez que first(...) présuppose un seul fichier. Pour une question autorisant plusieurs fichiers, la réponse revient sous forme d’un tableau d’objets, un par fichier ; il faut donc parcourir le résultat de l’analyse avec Apply to each pour récupérer les fichiers un par un (si une seule pièce jointe suffit pour la demande, il est plus simple de fixer la limite de la question elle-même à un seul fichier). Par ailleurs, le connecteur utilisé pour récupérer le fichier doit correspondre à l’emplacement d’enregistrement ci-dessus : pour un formulaire personnel, le connecteur OneDrive for Business ; pour un formulaire de groupe, comme l’emplacement d’enregistrement est le site SharePoint du groupe, indiquez ce site avec le connecteur SharePoint pour la récupération. Un mélange classique où l’on trébuche consiste à chercher un fichier d’un formulaire de groupe avec le connecteur OneDrive et à ne pas le trouver.

Si vous faites circuler le fichier reçu en pièce jointe d’une demande d’approbation, transmettez le contenu du fichier en binaire au champ de pièce jointe.¹² Toutefois, l’action d’approbation ne peut joindre à l’e-mail que des fichiers jusqu’à 5 Mo ; au-delà, l’approbateur devra consulter la pièce jointe dans la liste d’approbations du portail Power Automate.⁸ Pour les fichiers volumineux, il est plus fiable de les enregistrer dans SharePoint et de faire circuler un lien plutôt que la pièce jointe elle-même.

5. Faire fonctionner l’accueil avec Power Automate

La forme de base : 2 étapes + 3 sorties

Forms n’informe personne par défaut, même quand une réponse arrive (il existe des paramètres de notification côté propriétaire du formulaire, mais on ne peut choisir ni le destinataire ni le contenu du texte¹⁰). Faire fonctionner l’accueil comme un processus métier, c’est le travail de Power Automate. La forme de base du flux tient en deux étapes : le déclencheur « Quand une nouvelle réponse est envoyée », qui désigne le formulaire, suivi de « Obtenir les détails de la réponse », qui extrait la réponse à chaque question comme contenu dynamique.² Les sorties qui suivent sont au nombre de trois : « enregistrement dans le registre », « notification d’accueil au demandeur » et « notification à l’équipe responsable ».

flowchart TD
    Submit[Le demandeur envoie via Forms<br/>Restreint à l'organisation, connecté] --> Trigger[Quand une nouvelle réponse est envoyée<br/>Déclenchement du flux cloud]
    Trigger --> Details[Obtenir les détails de la réponse<br/>Réponses converties en contenu dynamique]
    Details --> Record[Création d'un élément dans la liste SharePoint<br/>Statut : reçu]
    Record --> Ack[E-mail de confirmation d'accueil au demandeur<br/>Insertion d'une copie du contenu de la réponse]
    Record --> Team[Publication dans la chaîne Teams de l'équipe responsable]
    Record --> Need{Type nécessitant une approbation ?}
    Need -- Oui --> Approval[Vers le flux d'approbation<br/>Démarrer et attendre une approbation]
    Need -- Non --> Work[Attribution d'un responsable et traitement]
    Approval --> Back[Réécriture du résultat dans la liste]
    Work --> Back2[Mise à jour de l'état d'avancement via la colonne de statut]

C’est l’endroit où l’écart entre le schéma conceptuel et l’écran réel est le plus déroutant ; les étapes de clic pour construire ce schéma tel quel sont donc détaillées ci-dessous. Créez au préalable la liste SharePoint de destination de la transcription.

1. Ouvrez le portail Power Automate et, dans le menu de gauche, sous « Créer », choisissez « Flux cloud automatisé ». Saisissez le nom du flux.
2. Dans le champ de recherche du déclencheur, tapez « Forms » et choisissez « Quand une nouvelle réponse est envoyée ».²
3. Dans le « Form ID » du déclencheur, sélectionnez le formulaire. Un formulaire de groupe n’apparaissant pas dans la liste, collez la valeur après FormId= dans l’URL de l’écran d’édition du formulaire (chapitre 3).³
4. « Nouvelle étape » → champ de recherche « Forms » → action « Obtenir les détails de la réponse ». Indiquez à nouveau le même formulaire, et dans « ID de la réponse », saisissez le contenu dynamique du déclencheur « ID de la réponse » (il est parfois déjà rempli automatiquement).²
5. « Nouvelle étape » → « SharePoint » → « Créer un élément ». Choisissez l’adresse du site et le nom de la liste, puis affectez à chaque colonne le contenu dynamique (la réponse à chaque question) de « Obtenir les détails de la réponse ». Placez dans la colonne de statut une valeur fixe telle que reçu.
6. « Nouvelle étape » → « Office 365 Outlook » → « Envoyer un e-mail (V2) ». Dans « À », placez le contenu dynamique Responders’ Email, et rédigez dans le corps une copie du contenu de la réponse ainsi qu’un délai indicatif.¹⁰
7. « Nouvelle étape » → « Microsoft Teams » → « Publier un message dans une conversation ou une chaîne ». Choisissez l’équipe et la chaîne de l’équipe responsable, et incluez le type, l’échéance, le demandeur et un lien vers l’élément de liste.
8. En haut à droite, « Enregistrer » puis « Tester » pour lancer un test manuel, en envoyant réellement une réponse depuis le formulaire. Ouvrez les entrées et sorties de chaque étape pour vérifier que les valeurs sont bien celles attendues.

L’ajout du branchement vers l’approbation vient après. Il est plus sûr de d’abord faire fonctionner de bout en bout les étapes 1 à 8 seules — « une réponse envoyée apparaît dans le registre, un e-mail part vers le demandeur, une notification arrive dans l’équipe » — avant d’empiler les branchements conditionnels.

Transcription vers une liste SharePoint — construire le registre d’accueil

La demande reçue est transcrite ligne par ligne dans une liste SharePoint dès le début du flux. Le point important, c’est de doter la liste, en plus de la copie de la réponse, de « colonnes de gestion » absentes du formulaire.

Regrouper dans cette liste (ou dans le fil Teams associé à l’élément de liste) — plutôt que de les disperser dans des e-mails — les questions complémentaires adressées au demandeur et l’historique des échanges permet de rassembler en un seul endroit les traces qui évitent les désaccords sur « qui a dit quoi ». Une vue filtrée sur « statut = non terminé » devient directement la liste des dossiers en cours utilisable telle quelle en réunion du matin. Il existe aussi des modèles pour transcrire vers Excel¹⁰, mais pour un registre où plusieurs personnes mettent le statut à jour en continu, une liste — avec ses vues, ses types de colonnes et son historique de versions — est mieux adaptée. La logique de migration d’un registre Excel vers une liste est résumée dans « Remplacer un registre Excel par une liste SharePoint — en finir avec le « registre qui casse » grâce au partage, à l’historique et à la liaison avec les flux ».

Notification d’accueil — répondre « c’est bien reçu » dans la première minute

C’est ici que l’écart ressenti avec une demande par e-mail est le plus grand. Le flux émet deux types de notifications.

• L’e-mail de confirmation d’accueil au demandeur. Pour un formulaire restreint à l’organisation, il peut être envoyé directement via le connecteur Outlook, à l’adresse e-mail du répondant (Responders’ Email) contenue dans les détails de la réponse.¹⁰ Insérez dans le corps une copie du contenu de la réponse et un délai indicatif du type « le responsable vous contactera sous 3 jours ouvrés ». La principale cause qui pousse un demandeur à relancer, c’est de ne même pas savoir si sa demande est bien arrivée ; cet unique message réduit considérablement le nombre de sollicitations. Forms lui-même propose aussi un réglage d’e-mail de confirmation au répondant, mais c’est l’envoi depuis le flux qui permet d’adapter le texte au métier.¹⁰
• La notification Teams à l’équipe responsable. Envoyer vers l’adresse e-mail d’un individu recréerait une dépendance à une seule personne ; publiez donc dans la chaîne de l’équipe responsable. En y plaçant le type, l’échéance, le demandeur et un lien vers l’élément de liste, la chaîne devient directement « la boîte de réception des nouvelles demandes ».

Se relier à l’approbation

Un type de demande comme « l’achat de logiciel nécessite l’approbation d’un supérieur » se relie, depuis le flux d’accueil, à l’action d’approbation (démarrer et attendre une approbation). Il existe aussi des modèles pour insérer le contenu de la réponse Forms dans la demande d’approbation, permettant de construire d’un seul tenant jusqu’au renvoi d’un e-mail de résultat au demandeur selon le résultat de l’approbation.¹⁰ Les points de conception comme les types d’approbation, la gestion des délais et des relances, et la façon de conserver l’historique des approbations, sont détaillés dans « Créer un flux d’approbation avec Power Automate — numériser les circuits de validation et les demandes sur papier et par e-mail », que vous pouvez consulter. Une fois que le flux d’accueil fonctionne de manière stable, pensez rapidement aussi à configurer un copropriétaire du flux et une notification en cas d’erreur (la conception de la gestion des erreurs est traitée dans « Gestion des erreurs et conception des tentatives dans Power Automate »).

6. Les limites de Forms seul — pourquoi la transcription en liste devient la solution de référence

Vouloir faire tenir tout l’accueil dans Forms seul se heurte aux murs suivants.

• Le statut après envoi n’est pas visible. Par défaut, un répondant ne peut pas modifier après coup le contenu envoyé. Certains environnements déploient un réglage côté créateur autorisant l’enregistrement et la modification de la réponse par le répondant lui-même, mais cela reste un simple moyen de correction du contenu. Ce que les paramètres du formulaire proposent, ce sont des éléments comme la date/heure d’ouverture et de fermeture de l’accueil ou la limite à une réponse par personne⁶ ; il n’existe pas d’écran permettant de vérifier où en est sa propre demande (reçue, en cours, terminée), et il est plus juste de considérer qu’aucune fonction ne prend en charge « l’après-envoi ». Dans un environnement où la modification n’est pas autorisée, si une correction se fait par « un nouvel envoi », c’est au récepteur de déterminer laquelle des deux versions est la plus récente.
• La gestion de la liste des réponses est faible. L’écran des réponses de Forms est fait pour l’agrégation et la consultation ; il ne peut porter ni colonne de statut ni responsable, et ne permet pas non plus d’« afficher uniquement ce qui n’est pas traité ». Ce qu’exige la gestion d’un accueil, c’est une fonction de « mise à jour continue » de la liste, ce qui sort du domaine de Forms.
• Le plafond se fait sentir par les fonctionnalités avant le volume. Un formulaire lié à un compte professionnel ou scolaire peut recevoir jusqu’à 5 000 000 réponses par formulaire, avec 200 questions et 4 000 caractères par réponse texte (il existe aussi une limite de 200 000 caractères au total des réponses texte pour un seul envoi, mais c’est un plafond qu’un répondant peut atteindre au cours d’un seul envoi, pas un plafond atteint par l’accumulation des réponses). En pratique, ce qui limite en premier n’est pas le volume mais les fonctionnalités : au-delà de 50 000 réponses, le graphique de synthèse, la consultation des réponses individuelles, l’impression, etc. deviennent indisponibles, et seule l’extraction par export CSV reste possible.⁷ Un accueil interne atteint quasiment jamais la limite de volume, mais pour un formulaire exploité sur le long terme, c’est la conception même de « tout accumuler dans Forms » qui finit par peser. La pratique recommandée consiste à exporter puis à effacer les réponses une fois qu’elles s’accumulent¹¹ ; dans tous les cas, il faut de toute façon un autre emplacement pour l’historique.

Autrement dit, Forms excelle comme « outil pour distribuer un format de saisie », mais ce n’est pas un « outil pour gérer ce qui vient après l’accueil ». La répartition des rôles qui suit les points forts respectifs de chacun est celle-ci : Forms est le point d’accueil, le registre et la gestion des statuts relèvent de la liste SharePoint, la notification et l’intégration relèvent de Power Automate.

7. Jusqu’où recevoir avec Forms — tableau de décision

Le choix de l’outillage pour l’accueil se fait par étapes. Voici un tableau indicatif.

Pour se faire une idée rapide, la règle est : « tant que le demandeur est en interne, Forms tient bon ; dès que l’externe s’en mêle, il faut changer de conception ». La question de repenser depuis la base le point d’accueil des échanges papier, fax et pièces jointes e-mail avec l’extérieur est traitée dans « Faire migrer les commandes par FAX vers le web — concevoir la période de double fonctionnement et une migration par étapes » et « Automatiser le traitement des bons de commande et factures PDF reçus par e-mail avec Power Automate — conception de l’enregistrement, du tri, de la notification et de la lecture ».

8. Conclusion

Ce qui rend pénibles les demandes par e-mail et à l’oral, c’était que le volume total des demandes n’existait nulle part, que le format n’était pas uniforme, et que le statut n’était pas visible. En unifiant l’entrée avec Microsoft Forms, en automatisant « qui a envoyé la demande » via la restriction à l’organisation et l’enregistrement du nom, et en renvoyant, dès l’instant de l’accueil, un enregistrement en registre et une notification d’accueil avec Power Automate — ce seul modèle fait déjà largement disparaître les échanges du type « et cette affaire, où ça en est ? »

Les points clés de la conception sont : un formulaire centré sur les choix qui ne fait pas trop écrire, la compréhension de la différence entre restriction à l’organisation et anonymat, la maîtrise des contraintes du téléversement de fichiers (organisation uniquement, 10 fichiers maximum, 1 Go maximum par fichier), et ne pas attendre de Forms qu’il tienne lieu de registre. Forms est le point d’accueil, la liste est le registre, le flux assure la notification et l’intégration. Un accueil qui respecte cette répartition des rôles continue de fonctionner longtemps, même quand le responsable change. Et quand l’accueil depuis l’extérieur, les pièces jointes, le volume et les besoins d’intégration prennent de l’ampleur, c’est le moment d’envisager le développement d’un formulaire web ou d’un système dédié.

La prochaine étape — liste de contrôle pour construire le premier accueil

Vouloir centraliser d’un coup toutes les demandes dans un seul formulaire fait grimper le nombre de questions, et plus personne ne l’utilise. Faites d’abord fonctionner un seul type de demande.

• Choisir un seul type de demande à cibler (les demandes nombreuses et de format flottant s’y prêtent bien)
• Limiter les questions à 5-10. Toujours inclure le type de demande, l’échéance et le complément
• Régler le texte libre en « réponse longue » (pour éviter le problème des 255 caractères du texte sur une ligne — chapitre 3)
• Régler la diffusion sur « restreinte à l’organisation » et activer « enregistrer le nom »
• Créer le formulaire comme formulaire d’un groupe (équipe), pas comme formulaire personnel
• Créer d’abord la liste SharePoint de destination de la transcription. Toujours y inclure les 3 colonnes statut, responsable et note de traitement
• Construire le flux dans l’ordre « Obtenir les détails de la réponse → Créer un élément → E-mail de confirmation d’accueil → Publication Teams », et le faire passer une fois en exécution de test
• Écrire dans l’e-mail de confirmation d’accueil « d’ici quand, quoi va se passer »
• Ajouter au moins un copropriétaire au flux (pour pouvoir corriger même si le créateur est absent)
• Exploiter pendant 2 semaines, puis ajouter au formulaire les questions correspondant aux points ayant nécessité une clarification

Une fois cela accompli, ajoutez les types de demandes un par un. Ce qu’il faut augmenter, ce n’est pas le nombre de questions du formulaire, mais les choix de type et les branchements.

Articles connexes

• Créer un flux d’approbation avec Power Automate — numériser les circuits de validation et les demandes sur papier et par e-mail
• Remplacer un registre Excel par une liste SharePoint — en finir avec le « registre qui casse » grâce au partage, à l’historique et à la liaison avec les flux
• Automatiser les processus métier avec Power Automate — Flux cloud, flux de bureau et gestion robuste des erreurs
• Automatiser le traitement des bons de commande et factures PDF reçus par e-mail avec Power Automate — conception de l’enregistrement, du tri, de la notification et de la lecture

Domaines de conseil associés

合同会社小村ソフト (Komura Software LLC) prend en charge les projets allant du conseil sur la construction d’un mécanisme d’accueil, de registre et de notification pour les processus métier internes tirant parti de Microsoft 365, jusqu’au développement de formulaires web externes et de systèmes métier qui dépassent ce que Forms peut couvrir.

• Conseil technique et revue de conception
• Développement d’applications Windows
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

La question de téléversement de fichier de Microsoft Forms peut-elle être utilisée par des personnes extérieures à l'organisation ?

Non. La question de téléversement de fichier ne peut être ajoutée que lorsque la diffusion du formulaire est réglée sur « seuls les utilisateurs de mon organisation peuvent répondre » (ou des utilisateurs spécifiques de l'organisation) ; dans un réglage qui autorise les réponses depuis l'extérieur de l'organisation, cette question elle-même devient indisponible. Les fichiers téléversés sont enregistrés dans le OneDrive for Business de l'organisation, avec un maximum de 10 fichiers par question et une limite par fichier à choisir parmi 10 Mo, 100 Mo ou 1 Go. Si vous devez recevoir des pièces jointes de l'extérieur, envisagez d'utiliser en complément la fonction de demande de fichiers de OneDrive/SharePoint, ou le développement d'un formulaire web.

Combien de réponses un formulaire Microsoft Forms peut-il recevoir au maximum ?

Un formulaire lié à un compte professionnel ou scolaire peut recevoir jusqu'à 5 000 000 réponses (50 000 pour les environnements GCC High/DoD). Pour un accueil interne de demandes et requêtes, cette limite elle-même ne pose quasiment jamais problème, mais au-delà de 50 000 réponses, des fonctions comme l'affichage des graphiques de synthèse ou la consultation des réponses individuelles deviennent indisponibles, et seule l'extraction par export CSV reste possible. Comme la liste des réponses ne dispose d'aucune fonction de gestion des statuts, il est de règle, quel que soit le volume, de transcrire les demandes reçues vers une liste SharePoint via Power Automate pour en faire un registre.

Peut-on enregistrer automatiquement qui a répondu au formulaire ?

Oui, si la diffusion est restreinte à l'organisation. En réglant « seuls les utilisateurs de mon organisation peuvent répondre » et en activant « enregistrer le nom », le nom et l'adresse e-mail du répondant sont automatiquement enregistrés avec la réponse, sans qu'il soit nécessaire de faire saisir le nom ou le service. L'option de limitation à une réponse par personne n'est elle aussi disponible que dans ce cas. À l'inverse, si vous réglez « tous les utilisateurs peuvent répondre », les réponses deviennent anonymes et rien n'indique qui les a envoyées. Le point d'accueil des demandes et requêtes internes doit, en principe, rester restreint à l'organisation.

Faut-il construire le point d'accueil des demandes avec Forms ou avec une liste SharePoint ?

Si vous privilégiez la facilité de saisie pour le demandeur, choisissez Forms ; si vous privilégiez la gestion en registre, choisissez une liste SharePoint. Forms se remplit facilement depuis un smartphone et permet de configurer simplement les branchements de questions et les champs obligatoires, mais présente une faiblesse côté gestion des accueils : impossible de modifier après envoi ou de suivre l'avancement, et la gestion de la liste des réponses reste limitée. En pratique, une configuration « recevoir avec Forms puis transcrire vers une liste SharePoint via Power Automate » permet de concilier facilité de saisie et gestion en registre. Pour une demande standardisée à nombreuses colonnes, où tous les saisisseurs savent manipuler une liste, recevoir directement via le formulaire de la liste est aussi une option.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.