Simulateur d'admission ASTPrep : scoring et emails

ASTPrep prépare aux admissions sur titre en école de commerce : TAGE MAGE, épreuves orales, ESSEC, ESCP, EDHEC, SKEMA. La demande était qu’un candidat puisse estimer ses chances d’admissibilité, école par école, depuis leur site. Avec le résultat envoyé par email et le contact remonté automatiquement dans le CRM.

Le simulateur est en ligne et accessible depuis la navigation d’astprep.com.

Ce qui a été construit

Un formulaire, un moteur de calcul, deux branchements.

Le formulaire reprend une maquette Figma fournie, en Twig et HTML. Le moteur de calcul applique les barèmes d’ASTPrep : conditions, pondérations, bonus, et restitution d’une probabilité par école visée. Les règles vivent dans un fichier JSON séparé du code, ce qui permet à l’équipe de les mettre à jour sans me rappeler.

Ensuite, deux connexions. Brevo pour l’envoi de l’email de résultat, avec les variables du candidat injectées dans les modèles existants. Attio pour le CRM : le lead part dans le pipeline avec ses scores, ses écoles ciblées et son résultat, sans ressaisie.

Les enregistrements DNS de délivrabilité — SPF, DKIM, DMARC — ont été configurés en même temps. Un email de résultat qui atterrit en indésirable ne sert à rien, et c’est ce qui arrive par défaut quand on branche un outil d’envoi sur un domaine qui n’a jamais servi à ça.

Le chiffre

Six jours de travail, de la réunion de cadrage à la mise en production. Répartis en un jour et demi de cadrage et de formalisation des barèmes, trois jours de développement, une demi-journée pour les deux branchements, une journée de recette avec le client.

Le cadrage représente un quart du total. C’est normal sur ce type de projet : traduire un arbre décisionnel écrit à la main en règles exécutables prend plus de temps que de l’implémenter ensuite.

Aucune IA dedans, et c’est voulu

Un simulateur de scoring est exactement le cas où il ne faut pas de modèle de langage. Deux candidats qui remplissent le même formulaire doivent obtenir le même résultat, aujourd’hui et dans six mois. Un moteur de règles déterministe garantit ça ; un modèle génératif ne le garantit pas.

C’est la distinction qui structure mon travail : un agent décide et agit dans une boucle, une automatisation enchaîne des étapes prévisibles entre deux logiciels. Les confondre est ce que font beaucoup de pages de prestataires. Ici, l’automatisation était la bonne réponse, et elle coûte moins cher.

Les limites

Le simulateur donne une probabilité d’admissibilité, pas une décision d’admission. La différence est écrite sur le résultat envoyé au candidat.

Et la qualité du résultat dépend entièrement des barèmes fournis par ASTPrep. Je les ai formalisés, je ne les ai pas validés : si un barème est faux en entrée, le score est faux en sortie. C’est pour cette raison que le fichier de règles est modifiable par le client sans intervention de ma part.

Faire chiffrer un cas comparable · Comment je mesure avant de construire