Ma démarche · IA & apprentissage
Développer et apprendre à l’ère de l’IA : ma démarche et les réflexes utiles
De l’inspiration à Figma, du code à sa compréhension : ma démarche de création web et des réflexes concrets pour progresser avec l’IA.
Mon objectif avec l’IA est de développer des sites plus aboutis tout en continuant à apprendre. Une interface qui prend forme rapidement offre un bon point de départ : elle donne quelque chose à observer, à questionner et à améliorer. Dans cet article, je pars d’un exemple de mon portfolio, la refonte Québec Signature, puis je propose des réflexes pour relier design, développement et compréhension du code.
1. Donner une direction au projet avant de générer
Pour ma proposition Québec Signature, j’ai commencé par chercher des inspirations sur Dribbble et Framer, puis construit une maquette dans Figma avant de l’améliorer avec l’IA. Framer servait ici de source d’inspiration. Ce parcours m’a permis de partir d’une direction visuelle avant d’aller plus loin dans la proposition.
Le point de départ reste le besoin : que doit comprendre la personne qui arrive sur la page, et quelle action doit-elle pouvoir faire ? Pour une refonte, comparer la version de départ et la proposition aide à parler de choix précis : ordre des informations, navigation, services et prise de contact. C’est sur ces décisions que l’IA peut ensuite apporter des pistes.
2. Choisir les outils selon leur rôle
Dans mes projets, les outils répondent à des besoins différents. Figma sert à préparer la maquette. MeFolio repose sur Laravel, MySQL et Tailwind CSS ; L’Expo associe React JS et Tailwind CSS à une API Laravel ; Rynva utilise Next.js, Tailwind CSS et Supabase. Ces exemples montrent qu’il n’y a pas une seule combinaison à appliquer à tous les sites.
Pour l’IA, une distinction utile consiste à séparer la discussion et l’action dans le code. Un assistant conversationnel peut aider à reformuler un besoin ou une explication. Un assistant intégré au projet peut proposer des modifications. Dans les deux cas, mieux vaut lui donner un périmètre clair, les contraintes existantes et le résultat attendu, puis examiner sa proposition avant de la garder.
3. Transformer une demande vague en petite étape vérifiable
Une demande comme « améliore cette page » laisse beaucoup de place à l’interprétation. Une consigne plus utile serait : « Rends ce formulaire utilisable sur téléphone, conserve les champs existants et explique les modifications. Prévois aussi le cas où l’envoi échoue. » Le résultat est plus facile à relire parce que l’objectif et les limites sont explicites.
Pour avancer sans perdre le fil, je recommande de traiter un composant ou un parcours à la fois. Regarder les fichiers modifiés, comparer le résultat au besoin et conserver une version fonctionnelle donne un cadre aux itérations. Si la proposition change davantage que prévu, il est préférable de réduire le changement avant d’ajouter une autre fonctionnalité.
4. Apprendre vite en faisant travailler sa compréhension
Un résultat généré devient plus utile pour apprendre quand on sait poser des questions précises : que reçoit cette fonction ? Que renvoie-t-elle ? Où la donnée change-t-elle ? Pourquoi cet état est-il nécessaire ? Demander une explication avec un petit exemple permet de cibler le point qui bloque, au lieu d’accumuler du code sans repère.
Un exercice simple consiste ensuite à fermer la réponse, expliquer le mécanisme avec ses propres mots et refaire une petite partie sans assistance. Puis changer une contrainte : ajouter un champ, gérer une liste vide ou modifier la règle de validation. Pouvoir prévoir ce qui va changer et retrouver la bonne partie du code donne un repère concret de compréhension.
La documentation garde une place essentielle pour vérifier une syntaxe, une option ou le comportement d’une API. Les modules d’apprentissage de MDN offrent notamment une base pour reprendre les fondamentaux du web. L’idée est de faire des allers-retours entre une question réelle, une explication et un essai personnel.
Références : MDN : les bases pour apprendre le développement web
5. Vérifier le site et ce qu’on sait en expliquer
La documentation de GitHub rappelle que les résultats proposés par ses agents doivent être revus et validés. Pour un site, un premier contrôle consiste à suivre le parcours attendu, puis à provoquer les cas moins favorables : saisie invalide, données absentes, réponse en erreur et double clic. Sur mobile, il faut aussi regarder les débordements, le menu et les champs quand le clavier s’ouvre.
Une vérification utile associe le comportement et son explication. Si un formulaire refuse une adresse incorrecte, peut-on montrer où cette règle est définie ? Si un bouton attend une réponse, sait-on ce qui réactive l’interface après une erreur ? Compléter ces essais par la navigation au clavier et des tests automatisés adaptés permet de garder des points de contrôle réutilisables.
Il faut enfin distinguer ce qui a été testé de ce qui reste à vérifier. Un build réussi confirme une étape technique ; il ne prouve pas, à lui seul, qu’un message arrive à destination ou que le parcours fonctionne sur un téléphone réel. Cette distinction aide à préparer la suite du travail.
Références : GitHub : usage responsable des agents Copilot
La démarche que je veux défendre est simple : partir d’une idée claire, lui donner une forme, utiliser l’IA pour explorer et avancer, puis prendre le temps de comprendre et de vérifier. Apprendre plus vite, c’est pouvoir réutiliser ce qu’on vient de découvrir sur le problème suivant. C’est cette autonomie que je cherche à développer en même temps que mes sites.
Un projet à créer ou à améliorer ?
Parlons-en ↗