Fabriquer une app avec l'IA.

Cadrer un projet d'app, pas un projet IA

Première règle, contre-intuitive : on ne fait pas un « projet IA ». On fait un projet d'application qui répond à un besoin réel, et on utilise l'IA comme moyen de production. Le critère de réussite reste l'utilité de l'app pour ses utilisateurs, pas la quantité d'IA dedans.

Pour le Renard Astucieux, le besoin était précis : ma fille avait besoin d'apprentissages numériques sans publicité, sans achat caché, sans capture d'attention. Aucune application existante ne cochait les trois cases. L'IA est arrivée comme accélérateur de fabrication, pas comme argument de vente.

Idéation assistée et critique pédagogique

Une fois le besoin posé, l'IA est utile en idéation pour sortir rapidement un nombre de variantes qu'on n'aurait pas le temps de produire seul. Le prompt utile :

Tu es game designer expérimenté en jeux éducatifs pour
enfants de [ÂGE], avec un parcours en sciences de
l'éducation.

Pour la compétence « [compétence visée, par exemple :
reconnaissance des syllabes] », propose 7 mécaniques de
mini-jeu radicalement différentes (geste, rythme, tri,
construction, course, observation, mémoire).

Pour chaque proposition, donne :
- nom du jeu (court)
- mécanique en deux phrases
- compétence cognitive principale travaillée
- point pédagogique fort
- une limite ou un piège à anticiper

Puis on trie. Les propositions « originales » qui ne tiennent pas la critique pédagogique (analogues à ce qui existe sans valeur ajoutée, exigeantes en motricité au-delà de l'âge cible) sont écartées. Le tri est humain, pas algorithmique.

Sur Renard, ce processus a fait émerger des mécaniques comme « Le réfectoire » (dénombrement avec tri par catégories culinaires), qui combine mathématiques et structuration du quotidien.

Choisir une stack technique compatible avec l'IA

Toutes les stacks ne sont pas équivalentes du point de vue de la productivité avec l'IA. Critères d'un bon choix :

• Forte présence dans les corpus d'entraînement. Les modèles connaissent très bien JavaScript/TypeScript, Python, React. Ils sont moins à l'aise sur des stacks plus rares (Elixir, Rust pour certains domaines, frameworks confidentiels).
• Outillage CLI. L'agent doit pouvoir lancer des commandes : npm run dev, npm test, npm run build. Une stack avec des outils CLI matures est massivement plus productive.
• Communauté et documentation. Quand l'agent bute, il peut chercher (mode agentique avec recherche web). Plus la doc est riche, plus il trouve.

Pour Renard : Next.js + React + Tailwind CSS + Konva pour le canvas 2D, le tout empaqueté avec Capacitor pour Android. Stack très standard, parfaitement maîtrisée par les agents.

Direction artistique générative

Avant de coder, on définit l'identité visuelle. Pour un jeu, c'est la moitié du travail. L'IA génère, le designer humain trie et corrige.

• Univers. Quelques visuels-clés (forêt, décors, ambiance lumineuse) pour fixer le ton. Sur Renard, deux ambiances : forêt de jour pour le Monde 1, forêt de nuit pour le Monde 2 (ajouté en 2026).
• Personnages. Le renard mascotte décliné en plus de trente costumes. Génération en lot, sélection manuelle, retouches pour la cohérence.
• UI/UX. Boutons, cadres, icônes. Tester avec un échantillon d'utilisateurs cibles tôt (parents, enseignants), parce que ce qui plaît à l'adulte qui dessine ne marche pas toujours avec l'enfant qui joue.

Outils : Midjourney, Flux, Stable Diffusion XL pour la génération, Photoshop ou Figma pour les retouches et l'export. L'agent peut aussi gérer la pipeline de redimensionnement (PNG par taille pour les stores).

Développement itératif en pair-programming agentique

Le cœur du travail. On construit map par map, mini-jeu par mini-jeu, dans un cycle court :

1. Décrire. Brief précis à l'agent : « Crée un composant ReactJeuLicornes qui présente une addition à l'écran, propose trois réponses, fait monter une licorne sur un fond de montagne à chaque bonne réponse, déclenche une animation de victoire à 5 bonnes réponses consécutives. »
2. Générer. L'agent écrit le code, ajoute les imports, configure les states.
3. Tester en local. npm run dev dans le terminal, ouverture du jeu dans le navigateur, test manuel.
4. Itérer. « Les boutons sont trop petits pour des doigts d'enfant », « ajoute un son à chaque bonne réponse », « la licorne disparaît trop vite quand elle arrive en haut ». L'agent corrige.
5. Valider. Tests automatiques (Jest, Playwright) écrits par l'agent pour les comportements critiques.

Sur Renard, 16 mini-jeux ont été produits ainsi en quelques mois, parallèlement à un emploi à temps plein.

Le cas dur, ajuster les détails pixel par pixel

Tous les modules ne sont pas égaux. Certains posent des problèmes que la génération standard ne résout pas. Le cas de figure type sur Renard a été l'atelier d'écriture cursive.

Les courbes des lettres en cursive (« f », « g », liaisons entre lettres) doivent correspondre précisément aux conventions scolaires belges et françaises pour que le geste appris soit transférable au papier. Une boucle de « g » trop ronde ou un « f » qui descend trop bas, et le module devient contre-productif.

Approche en mode agentique :

1. Donner à l'agent une référence visuelle (capture d'écran d'un manuel scolaire de référence).
2. Lui demander de générer une première courbe SVG, et d'afficher le rendu dans le navigateur.
3. Comparer visuellement, écrire un feedback précis (« la queue du g est trop courte, la boucle doit faire les deux tiers de la hauteur x »).
4. L'agent ajuste les points de contrôle Bézier, teste à nouveau.

Boucle qui a tourné plusieurs dizaines de fois pour l'alphabet complet. À la main, plusieurs jours d'ajustement. En agentique, quelques heures.

Sound design et accessibilité

Le son arrive en dernier, intentionnellement. Pendant les phases de tests fonctionnels, le son est fatigant. Une fois la mécanique stable, on ajoute :

• Ambiance musicale (générée par IA ou banque libre de droits, par exemple Suno, ElevenLabs Music, ou Freesound).
• Bruitages d'interaction (clic, victoire, erreur), calibrés pour ne pas être stressants.
• Voix synthétiques pour la consigne (utile pour les enfants qui ne lisent pas encore). ElevenLabs ou Coqui pour des voix françaises naturelles.

Côté accessibilité : zone de toucher minimum de 44 pixels (Apple HIG), contraste vérifié, sous-titres pour les consignes parlées, mode mono-tâche (un seul élément interactif à la fois pour les jeunes joueurs).

Tests terrain avec utilisateurs réels

C'est l'étape qui distingue un projet sérieux d'un projet de démo. Avant publication, le Renard est passé par 14 jours de tests avec une trentaine de testeurs externes (parents, enfants, enseignants). Méthodologie :

• Recrutement. Mixage parents, enfants de la tranche d'âge cible, professionnels de l'éducation. Pas que des proches qui disent toujours oui.
• Protocole. Phase libre (l'enfant joue comme il veut, l'adulte observe sans intervenir), puis phase guidée (l'adulte propose un mini-jeu spécifique à découvrir).
• Outils de remontée. Formulaire simple (Google Forms, Typeform), discussion 15 minutes en visio, ou simple email. Pas d'usine à gaz.
• Critères mesurés. Temps d'usage spontané, frustrations (taux d'abandon par mini-jeu), demandes de répétition (proxy d'engagement positif), retours qualitatifs.

Les retours ont produit des changements concrets : taille des boutons remontée, délais entre questions allongés pour les enfants plus lents, signe « − » ajouté dans le réfectoire, mode parental verrouillé par geste plus sophistiqué.

Conformité et publication store

Étape souvent sous-estimée. La publication sur les stores (Google Play, App Store) exige des éléments qu'il faut anticiper. L'agent peut générer la plupart, mais il faut vérifier humainement.

• Politique de confidentialité. Page hébergée, conforme RGPD, à jour des données réellement collectées (rien sur Renard, ce qui simplifie).
• Conditions d'utilisation. Document standard, adapté au public et au modèle économique.
• Captures d'écran. Une par mini-jeu important, dans les bons formats pour chaque store.
• Description Store. Titre, sous-titre, description longue, mots-clés. Travaillés avec l'IA mais relus.
• Classification d'âge. Programme « Designed for Families » sur Google Play pour le public enfants, avec règles strictes (pas de publicité, pas d'achat in-app caché, pas de collecte de données).
• Délai de validation. Compter une semaine pour Google Play, plus pour Apple App Store. À prévoir dans le planning.

Lancement organique et itération continue

Sur Renard, le choix a été zéro budget marketing. Stratégie organique :

• Contenu sur quelques canaux (YouTube court, LinkedIn, communauté Facebook de parents). Régulier, pas viral.
• Site officiel renardastucieux.be, sobre, qui présente le jeu sans survente.
• Bouche-à-oreille via les premiers testeurs satisfaits.

Après le lancement, l'itération continue. Le Monde 2 (huit nouveaux mini-jeux dont mémoire, tri, ponctuation, lecture de l'heure) a été ajouté en réponse directe aux retours des premiers utilisateurs. Cycle classique : publier tôt, observer, ajouter.

Ce qui ne marche pas, à ne pas reproduire

• Vouloir tout générer d'un coup. Demander à un agent de produire un jeu complet en une session ne fonctionne pas. C'est par décomposition en petits modules autonomes que ça tient.
• Laisser l'agent décider de la pédagogie. Il proposera ce qui est statistiquement courant, pas ce qui aide vraiment l'enfant à apprendre. La décision pédagogique reste humaine.
• Sauter la phase de test terrain. Un jeu testé seulement par soi-même et son entourage immédiat passe à côté des problèmes que les vrais utilisateurs rencontrent.
• Sous-estimer le coût des stores. Frais de compte développeur (25 $ unique Google, 99 $/an Apple), temps de mise en conformité, temps de validation.