Automatiser les inscriptions à une formation sans créer de doublons

Tous les dossiers ne suivent pas le même chemin

Automatiser les inscriptions à une formation ne consiste pas simplement à envoyer les réponses d'un formulaire dans son logiciel de gestion.

Entre la demande reçue et l'inscription réellement validée, il faut souvent :

• identifier le participant ;
• retrouver son entreprise ;
• déterminer la bonne session ;
• vérifier que les informations nécessaires sont présentes ;
• éviter les doublons ;
• traiter les dossiers incomplets ;
• déclencher ensuite les documents et e-mails utiles.

Le formulaire n'est donc que le point de départ.

1. Demande reçue→
2. Informations vérifiées→
3. Participant et entreprise identifiés→
4. Session déterminée→
5. Inscription validée→
6. Actions suivantes déclenchées

Le vrai sujet est de savoir ce qui peut avancer automatiquement et ce qui doit encore être vérifié.

Une demande n'est pas toujours une inscription

Lorsqu'une personne remplit un formulaire, plusieurs situations sont possibles.

Le dossier peut être complet et prêt à être traité.

Mais il peut aussi manquer une information, concerner une session qui n'est pas encore définie ou correspondre à une personne déjà présente dans le logiciel.

Il est donc utile de distinguer :

• la demande reçue ;
• la préinscription éventuelle ;
• l'inscription validée.

Cette logique existe déjà dans des logiciels comme Digiforma ou Dendreo.

Une nouvelle demande ne doit donc pas forcément créer immédiatement une nouvelle inscription.

Elle peut aussi devenir :

• un dossier incomplet ;
• une demande en attente ;
• un dossier à vérifier.

Participant, entreprise, session et inscription ne sont pas la même chose

C'est une distinction simple, mais importante.

Un participant est une personne.

Une entreprise peut regrouper plusieurs participants.

Une session correspond à une date ou une occurrence précise de la formation.

L'inscription relie le participant à cette session.

flowchart LR
A[Entreprise] --> B[Participant]
B --> C[Inscription]
D[Session] --> C

Cela évite par exemple de recréer la fiche d'un participant qui revient suivre une nouvelle formation.

Même chose pour une entreprise qui inscrit plusieurs salariés.

La règle de base est donc :

chercher ce qui existe déjà avant de créer de nouvelles fiches.

Faut-il utiliser le formulaire du logiciel de formation ou son propre formulaire ?

Avant de créer une automatisation autour de Make, n8n, Zapier ou d'une API, je regarderais ce que le logiciel de formation sait déjà faire.

Digiforma, Dendreo ou SmartOF proposent déjà différentes fonctions autour des formulaires, préinscriptions et inscriptions.

Si le parcours natif répond correctement au besoin, je l'utiliserais.

Une intégration devient surtout intéressante lorsque le processus commence ailleurs :

• formulaire spécifique sur le site ;
• CRM ;
• espace d'inscription pour les entreprises ;
• processus commercial particulier ;
• plusieurs outils à alimenter.

Le choix dépend donc moins de l'outil d'automatisation que du fonctionnement réel de l'organisme.

J'ai détaillé cette logique dans mon article sur les intégrations autour d'un logiciel de gestion pour organisme de formation.

Comment automatiser le traitement d'une inscription ?

1. Recevoir la demande

La demande peut venir du site, du catalogue de formation, du CRM ou directement du logiciel métier.

L'objectif est simplement de récupérer les informations utiles :

• participant ;
• entreprise ;
• formation ;
• session éventuelle ;
• coordonnées ;
• informations ou pièces nécessaires.

À ce stade, rien n'oblige encore à créer une inscription.

2. Vérifier que le dossier est exploitable

Toutes les demandes ne sont pas complètes.

L'automatisation doit donc pouvoir dire :

ce dossier peut continuer

mais aussi :

il manque quelque chose avant de continuer.

C'est souvent ce deuxième cas qui évite les erreurs.

3. Vérifier si le participant existe déjà

Avant de créer un nouvel apprenant, le système recherche si la personne existe déjà.

Si la correspondance est claire, sa fiche est réutilisée.

Si aucune fiche ne correspond, une nouvelle peut être créée.

Et si plusieurs fiches semblent possibles, mieux vaut demander une vérification.

flowchart TD
A[Participant recherché] --> B{Correspondance ?}
B -->|Oui| C[Réutiliser]
B -->|Non| D[Créer]
B -->|Doute| E[Vérifier]

Le but n'est pas d'empêcher toute création.

Il est simplement d'éviter de créer deux fiches pour la même personne.

4. Faire la même chose pour l'entreprise

Le problème est similaire avec les entreprises.

Un formulaire peut contenir :

ACME

alors que le logiciel possède déjà :

ACME France SAS

Le système doit donc essayer de retrouver l'entreprise existante avant d'en créer une nouvelle.

Lorsque le doute est trop important, la décision peut rester humaine.

5. Identifier la bonne session

Une demande peut directement concerner une session précise.

Dans ce cas, le rattachement est simple.

Mais d'autres demandes concernent uniquement une formation ou une demande INTRA qui doit encore être planifiée.

L'automatisation peut alors :

• rattacher le participant à une session existante ;
• laisser la demande en attente ;
• envoyer le dossier à la personne chargée de la planification ;
• éventuellement créer une nouvelle session si le fonctionnement de l'organisme le permet.

Il faut également vérifier que la session accepte toujours les inscriptions au moment où le dossier est traité.

6. Faire avancer le dossier selon son état

Une demande peut passer par différents états :

flowchart LR
A[Demande reçue] --> B[Incomplète]
A --> C[À vérifier]
A --> D[Prête]
B --> D
C --> D
D --> E[Inscription validée]

C'est une logique importante.

Une confirmation ne doit pas partir uniquement parce qu'un formulaire a été envoyé.

Elle doit partir parce que l'inscription est réellement validée.

Même chose pour les documents ou l'ouverture d'un accès apprenant.

Comment éviter les doublons ?

Il existe plusieurs types de doublons.

Le participant peut déjà avoir une fiche.

L'entreprise peut déjà exister.

La personne peut également être déjà inscrite à la même session.

L'automatisation doit donc vérifier séparément ces situations.

Par exemple :

Paul Martin existe déjà dans la base.

Ce n'est pas un problème.

Paul peut parfaitement suivre une nouvelle formation.

En revanche :

Paul Martin est déjà inscrit à la session SST du 14 octobre.

Dans ce cas, il faut éviter de créer une deuxième inscription.

Autre cas fréquent : une personne remplit le formulaire une seconde fois parce qu'elle n'est pas certaine que le premier envoi a fonctionné.

Le système doit pouvoir reconnaître que l'inscription existe déjà.

Éviter les doublons consiste donc moins à bloquer les nouvelles demandes qu'à vérifier ce qui existe déjà avant chaque création.

Que faire lorsqu'une information ou une pièce manque ?

Un dossier peut être parfaitement valable tout en étant incomplet.

Il peut manquer :

• une coordonnée ;
• une information sur l'entreprise ;
• une pièce jointe ;
• un justificatif ;
• une validation.

Dans ce cas, je ne créerais pas de fausse information pour permettre au processus de continuer.

Le dossier reste simplement dans un état :

incomplet

jusqu'à réception de l'élément attendu.

Une relance peut alors partir automatiquement.

Mais elle doit vérifier que l'information manque toujours au moment de l'envoi.

J'explique ce fonctionnement plus en détail dans mon article sur l'automatisation des relances administratives.

Que déclencher une fois l'inscription validée ?

Une fois le dossier réellement validé, plusieurs actions peuvent suivre :

• envoyer une confirmation ;
• générer ou préparer les documents ;
• envoyer une convocation ;
• créer un accès apprenant ;
• transmettre les informations à un LMS ;
• mettre à jour un CRM ou un outil interne.

L'inscription devient alors le point de départ des autres processus.

Les documents doivent néanmoins suivre leurs propres règles.

Une convocation ne devrait par exemple pas être envoyée si les horaires ou le lieu ne sont pas encore fiables.

C'est le sujet de mon article sur l'automatisation des conventions, convocations et attestations.

Que se passe-t-il si l'automatisation s'arrête au milieu ?

C'est un cas à prévoir dès le départ.

Imaginons :

1. le participant est créé ;
2. l'entreprise est retrouvée ;
3. une erreur empêche finalement la création de l'inscription.

Le participant existe alors dans le logiciel, mais son inscription n'a pas été finalisée.

Le système doit pouvoir :

• signaler que le dossier n'est pas terminé ;
• savoir quelles étapes ont déjà été réalisées ;
• reprendre le traitement sans recréer les mêmes fiches.

L'objectif n'est pas de construire un système technique complexe.

Il faut simplement qu'une erreur ne transforme pas automatiquement un dossier en problème administratif supplémentaire.

Quelles décisions garder humaines ?

Certaines situations ne valent pas la peine d'être automatisées à tout prix.

Par exemple :

• deux participants semblent correspondre à la même demande ;
• deux entreprises sont très similaires ;
• une information reçue contredit celle déjà présente ;
• une session est complète ;
• une décision commerciale doit être prise ;
• une demande INTRA nécessite encore une planification.

Dans ce cas, le système peut préparer le dossier et demander uniquement la décision nécessaire.

Le but n'est donc pas forcément une inscription 100 % autonome.

Le but est surtout que l'équipe n'intervienne plus sur les cas simples.

Exemple : une entreprise inscrit deux salariés

Prenons ACME, qui souhaite inscrire Paul et Sophie à une session SST.

L'entreprise existe déjà dans le logiciel.

Paul existe également parce qu'il avait déjà suivi une autre formation.

Sophie, en revanche, n'est pas encore enregistrée.

Le processus peut donc :

1. retrouver ACME ;
2. réutiliser la fiche de Paul ;
3. créer la fiche de Sophie ;
4. vérifier que la session SST accepte toujours les inscriptions ;
5. inscrire Paul et Sophie ;
6. déclencher les confirmations et étapes suivantes.

Si ACME remplit ensuite une nouvelle fois le formulaire, le système vérifie que les deux personnes sont déjà inscrites avant de créer quoi que ce soit.

C'est cette vérification qui fait la différence entre :

recopier automatiquement les données d'un formulaire

et :

automatiser réellement le processus d'inscription.

Natif, connecteur ou sur-mesure ?

L'IA n'est pas non plus nécessaire lorsqu'un formulaire fournit déjà des informations structurées.

Elle peut devenir intéressante lorsqu'une demande arrive sous forme de texte libre, par exemple :

« Paul ne pourra finalement pas venir mardi, pouvez-vous inscrire Sophie à sa place ? »

C'est un autre type de problème, abordé dans mon article sur les agents IA pour traiter les e-mails d'un organisme de formation.

Commencez par observer une inscription réelle

Avant d'automatiser, je prendrais un dossier récemment traité et je regarderais :

1. d'où vient la demande ;
2. comment le participant est identifié ;
3. comment l'entreprise est retrouvée ;
4. comment la session est choisie ;
5. ce qui peut bloquer le dossier ;
6. ce qui est créé dans le logiciel ;
7. ce qui se passe ensuite ;
8. quelles situations nécessitent encore une personne.

Si ces règles sont claires, l'automatisation devient beaucoup plus simple.

Le but n'est pas qu'un formulaire crée des fiches plus vite.

Le but est qu'une demande arrive dans le système, soit rattachée aux bonnes informations, avance lorsqu'elle est complète et fasse ressortir uniquement les dossiers qui nécessitent réellement une intervention.

Sources

• Digiforma — documentation sur les formulaires individuels d'inscription
• Digiforma — documentation sur les préinscriptions du catalogue en ligne
• Digiforma — documentation sur les automatisations depuis un formulaire externe
• Dendreo — documentation sur la gestion des inscriptions du catalogue public
• Dendreo — documentation sur l'auto-validation des préinscriptions
• SmartOF — documentation sur la gestion des inscriptions et des formulaires