Les actions automatiques peuvent être conditionnées par des critères : exécuter une action seulement si certaines conditions sont remplies. Créez des automatisations intelligentes qui s’adaptent au contexte.
Conditions sur les données
Conditionnez une action selon les données : envoyer un email spécifique si le financement est OPCO, un autre si c’est une entreprise. Le système adapte son comportement au contexte de chaque apprenant.
Conditions sur les états
Déclenchez une action selon l’état de complétion : envoyer une relance seulement si le document n’est pas encore signé, débloquer une étape seulement si le quiz est réussi à 70%.
Logique ET/OU
Combinez plusieurs conditions avec des opérateurs ET/OU : exécuter l’action si la condition A ET la condition B sont remplies, ou si la condition C OU la condition D est vraie.
« Actions conditionnelles » fait partie du module Automatisation et IA de Loop Formations, aux côtés de Remplissage automatique des programmes de formation, Vérifier ses automatisations avant l’envoi et Preuves Qualiopi rapprochées par l’IA.
Un organisme de formation ne traite pas de la même façon un salarié financé par son entreprise, un demandeur d’emploi orienté par un prescripteur et un particulier qui paie lui-même sa formation. Les actions conditionnelles permettent à Loop de tenir compte de ces différences sans multiplier les automatisations parallèles. Vous posez une condition sur les données du dossier ou sur son avancement, et l’action ne se déclenche que si elle est vérifiée. Une seule logique gère alors plusieurs situations, ce qui reste maintenable dans le temps.
Adapter le traitement au type de financement
Le financement conditionne une grande partie des documents et des messages. Un dossier pris en charge par une entreprise appelle une convention et un interlocuteur au service formation. Un dossier individuel appelle un contrat et des informations différentes sur les conditions de règlement. Sans condition, il faudrait soit envoyer les mêmes contenus à tout le monde, soit gérer chaque cas à la main, deux options également insatisfaisantes.
La condition sur les données du dossier résout ce point simplement. La même automatisation envoie un contenu ou un autre selon la nature du financement enregistré, sans que personne ait à se souvenir de la règle au moment de l’inscription. Cette fiabilité vaut surtout dans les périodes chargées, quand la vigilance individuelle baisse et que les erreurs d’envoi deviennent statistiquement inévitables.
Conditionner sur l’avancement réel du dossier
L’autre famille de conditions porte sur ce qui a été fait ou non. Relancer uniquement les apprenants dont le document n’est pas signé, ouvrir une étape seulement si l’évaluation précédente atteint le seuil que vous avez défini, notifier un formateur uniquement si le nombre d’inscrits dépasse un plancher : ces règles produisent des automatisations qui paraissent attentives plutôt que mécaniques.
L’effet perçu côté apprenant est important. Recevoir une relance pour un document déjà signé la veille discrédite immédiatement l’organisme et génère un appel au standard. Une condition bien posée évite cette situation, non pas parce qu’elle rend le système plus intelligent, mais parce qu’elle vérifie l’état réel du dossier au moment précis où l’action va être exécutée.
Combiner les critères sans construire une usine à gaz
Les opérateurs ET et OU permettent d’assembler plusieurs critères dans une même règle. La tentation est alors d’écrire des conditions très fines, qui couvrent tous les cas imaginables. Cette voie mène à des ensembles que plus personne ne comprend six mois plus tard, et que l’on n’ose plus modifier de peur de casser un comportement dont on ignore la portée exacte.
La règle pratique est de limiter le nombre de critères par condition et de préférer plusieurs règles lisibles à une règle unique très longue. Nommez explicitement chaque automatisation en indiquant sa cible, tenez une liste à jour, et vérifiez qu’aucune règle ne se recouvre au point d’envoyer deux messages proches au même destinataire. La lisibilité prime sur l’élégance technique.
Les points à retenir
- Conditions sur les donnéesType de financement, entreprise cliente, formation concernée ou site de rattachement peuvent orienter l’action déclenchée sans dupliquer l’automatisation entière.
- Conditions sur l’avancementDocument signé ou non, évaluation réussie, étape achevée : la règle vérifie l’état réel du dossier avant d’exécuter l’action prévue.
- Opérateurs ET et OUPlusieurs critères se combinent dans une même règle, ce qui permet de cibler précisément une population sans créer une automatisation par cas.
- Moins de relances inutilesLes messages ne partent qu’aux personnes réellement concernées, ce qui préserve la crédibilité de l’organisme et réduit les appels entrants d’explication.
- Règles nommées et listéesUn intitulé explicite et un inventaire tenu à jour permettent de retrouver la règle responsable d’un comportement, condition d’une maintenance sereine.
Un organisme mixte entreprises et particuliers
Un organisme de formation en langues accueille des salariés financés par leur entreprise et des particuliers qui financent eux-mêmes leur parcours. Les documents et les modalités de règlement diffèrent, mais l’équipe envoyait jusque-là le même message de démarrage à tout le monde, complété par un appel téléphonique pour les cas particuliers. La chargée d’administration a mis en place une condition sur le type de financement enregistré dans le dossier : les salariés reçoivent les informations relatives à la convention et à leur interlocuteur entreprise, les particuliers reçoivent celles qui concernent leur contrat et leurs échéances. Une seconde condition, portant sur la signature effective du document, empêche l’envoi de toute relance à une personne déjà en règle. Le standard reçoit nettement moins d’appels de clarification en début de session.
Questions fréquentes
Que se passe-t-il si la condition n’est jamais remplie ?
L’action ne s’exécute simplement pas. Ce comportement est logique mais peut surprendre : un message attendu qui ne part jamais fait souvent croire à un dysfonctionnement, alors que la condition n’a jamais été satisfaite. Lors de la mise en place, vérifiez sur des dossiers réels que la donnée testée est bien renseignée. Une condition portant sur un champ vide dans la moitié des dossiers ne produira aucun effet visible.
Peut-on tester une condition avant de l’activer largement ?
Oui, et c’est vivement conseillé. Activez la règle sur un périmètre restreint, par exemple une seule session ou un seul site, et observez les envois réels pendant quelques jours. Vérifiez surtout les cas limites : dossier sans financement renseigné, apprenant inscrit tardivement, document signé juste avant l’exécution. Ces situations frontières révèlent presque toujours un ajustement à faire sur la formulation de la condition.
Comment éviter que deux règles envoient des messages redondants ?
Tenez un inventaire de vos automatisations avec, pour chacune, son déclencheur, sa condition et son destinataire. Avant d’ajouter une règle, vérifiez qu’aucune existante ne cible déjà la même population dans la même situation. Le recouvrement est la cause la plus fréquente de messages en double, et il est souvent invisible au moment de la création puisque chaque règle prise isolément paraît parfaitement justifiée.
Les conditions peuvent-elles gérer les cas de cofinancement ?
Un dossier avec plusieurs financeurs demande une attention particulière, car la donnée testée doit refléter la situation réelle. Renseignez précisément la répartition dans le dossier avant de construire la règle. Dans les configurations complexes, il est souvent plus sûr de traiter ces dossiers manuellement et de réserver l’automatisation aux cas simples, majoritaires en volume. Une automatisation ne doit jamais masquer une situation financière qui mérite un examen humain.
