En formation, j'ai remarqué que les élèves utilisaient l'IA comme une machine à réponses. J'ai construit un outil pour les aider à l'utiliser comme un vrai tuteur.
Ce projet ne vient pas d'une idée : il vient d'une salle de classe.
En tant que formateur en bootcamp, je voyais le même scénario chaque semaine : un élève bloqué colle « donne-moi la solution » dans ChatGPT. Sans contexte, sans l'erreur complète, sans montrer ce qu'il a essayé. Il obtient une correction qu'il ne comprend pas, ou une réponse trop avancée pour son niveau. Il avance dans l'exercice, pas dans l'apprentissage.
Le mauvais réflexe n'est pas d'utiliser l'IA. C'est de lui demander une solution au lieu de lui poser un problème.
Prompts flous, erreurs tronquées, zéro contexte, copie de la réponse sans la relire : le résultat est une faible compréhension et une dépendance qui s'installe. Interdire l'IA aurait été absurde. L'objectif était de transformer le réflexe : clarifier le problème, formuler une vraie demande, obtenir un indice plutôt qu'une correction, et garder une trace de ce qu'on a appris.
Deux pièces qui se répondent : un assistant qui construit le message, une méthode qui cadre le moment de l'utiliser.
L'élève choisit sa situation : « Je suis bloqué », « Je veux comprendre » ou « Je veux garder une trace », puis arrive sur un formulaire adapté : erreur de terminal, énoncé incompris, demande d'indice, notion floue, vérification de compréhension, explication de code ou fiche d'erreur. Quelques champs guidés, et l'app génère un message structuré à coller dans ChatGPT ou Claude. Il ne cherche plus ses mots : il décrit son problème.
Chercher seul environ dix minutes, demander à un binôme, utiliser l'IA avec un prompt clair, et appeler le formateur seulement après avoir vraiment essayé. Pas un cours théorique : un cadre simple, rassurant et actionnable, affiché dans l'app et utilisable en cours. L'IA a une place dans la méthode : la troisième, pas la première.
Les messages générés embarquent les consignes qu'un bon tuteur donnerait : « explique-moi avec des mots simples », « dis-moi où regarder en premier », « ne corrige pas tout directement : donne-moi d'abord un indice », « à la fin, fais-moi un récapitulatif de ce que je dois retenir ». La valeur du produit n'est pas dans le code : elle est dans la structure de ces messages.
Ce que j'ai décidé de ne pas construire compte autant que le reste.
La valeur est dans l'UX, la clarté du contenu et la structure des prompts. Ajouter de l'infra n'aurait servi qu'à faire sérieux.
« Pas de panique. Une erreur, c'est juste le code qui te dit où regarder. » Chaque libellé est écrit pour un débutant qui doute.
« Copie-colle, pas une capture » · « le fichier concerné, pas le projet entier ». Les contraintes des formulaires sont des leçons déguisées.
Le bouton « Copier mon message » reste désactivé tant que les champs obligatoires sont vides. On ne peut pas envoyer un prompt flou.
« Donne-moi la solution », collé tel quel. Une correction reçue, rien de compris, et le même blocage la semaine suivante.
Un blocage transformé en demande claire : contexte, erreur exacte, code concerné, et un indice demandé plutôt qu'une solution.
Ce n'est pas mon projet le plus technique, et c'est voulu. Il montre autre chose : partir d'un problème observé sur le terrain, le transformer en outil concret, et écrire une expérience pour un public non expert. Observation, UX writing, design, front-end : le rôle complet, sur un usage réel.