« Le développement front-end moderne est trop compliqué. Par où commencer ? »
Imaginez recevoir cette question. La personne connaît le back-end et veut ajouter une interface web à son petit outil. Elle ouvre un modèle de projet, découvre routage, compilation, gestion d’état et dépendances inconnues. Après deux soirées, aucune première donnée ne s’affiche.
Vous pouvez envoyer un tutoriel. Ou demander : « Après le week-end, souhaites-tu avoir appris cette partie ou que d’autres puissent déjà utiliser ton outil ? »
Ces deux souhaits se cachent souvent dans la même demande, mais conduisent ailleurs.
Pour apprendre, un petit projet débarrassé de la plupart des dépendances peut être un meilleur départ qu’un cours complet. En décomposant avec lui récupération des données, affichage d’une liste et traitement d’un clic, on relie ses acquis au nouveau travail. Pour partager vite, une interface existante ou l’aide brève d’un développeur peut être plus directe.
Dans cette conversation fictive, la question initiale n’a pas été mal comprise. Elle n’était pas encore une tâche précise. La réponse a participé à sa formation.
Beaucoup de systèmes attendent l’ordre inverse : définir le besoin, décrire les compétences, apparier. Cela convient à qui sait déjà ce qu’il veut. Pour qui cherche encore, une grande part du travail reste hors du système.
Je m’intéresse davantage à la possibilité de partir d’une expression incomplète et de la préciser grâce aux réponses.
La réponse ne vient pas forcément de la personne la plus expérimentée. Un apprenant passé récemment par le même détour peut repérer le terme qui bloque. Un mainteneur de modèle peut fournir un départ assez petit. Un ami incapable d’aider directement peut présenter quelqu’un. Expérience semblable, capacité complémentaire et mise en relation apportent des aides différentes.
Elles n’ont pas à arriver ensemble. Une page qui fonctionne peut suffire à reprendre seul. Seule la difficulté restante appelle une autre relation. Réunir trois experts dans la conversation peut devenir plus difficile à coordonner que le problème technique initial.
L’IA peut effectuer ici un travail minutieux : transformer les éléments dispersés en invitation facile à prendre en charge.
J’ai une API qui retourne du JSON et souhaite obtenir une page de liste partageable avant le week-end. Je sais écrire le back-end, mais connais mal la construction front-end. Voici un exemple minimal de l’API. Quelqu’un pourrait-il consacrer une demi-heure à m’aider à choisir un point de départ simple ?
Objectif, départ et périmètre permettent à l’autre d’évaluer son aide. L’invitation peut encore évoluer : une demi-heure suffit peut-être pour choisir l’outil, pas pour apprendre à l’utiliser. Après avoir vu une page minimale, la personne peut décider d’apprendre sérieusement plutôt que publier vite.
Chaque personne trouvée apporte alors aussi une occasion de corriger le problème. La recherche suivante peut viser quelqu’un de différent.
L’évaluation du système de découverte change. Une liste pertinente est un résultat intermédiaire ; il faut regarder ce que l’aide laisse : un premier écran, des matériaux pour continuer, une redistribution du travail vers la bonne personne. Et combien de temps les deux parties y consacrent.
Si le résultat est simplement dix onglets supplémentaires, nous ne l’avons pas encore aidé à sortir de ses deux soirées bloquées.
La découverte qui intéresse ToWow peut commencer là : permettre à quelqu’un qui ne sait pas encore décrire précisément sa difficulté d’obtenir une aide essayable. Une prochaine étape assez petite peut se produire ; une réponse assez concrète peut transformer la première phrase.