Bref… j‘ai écrit mon premier plugin local pour Moodle, avec une IA générative en mode #vibecoding.
Pour implémenter une nouvelle fonctionnalité à venir prochainement sur notre plateforme DiDaXo.tv (on vous en reparlera), nous avions besoin d’une fonctionnalité, inexistante selon moi, dans le répertoire des extensions Moodle. Il fallait donc développer.
En deux mots, je voulais un bouton CTA (Call To Action) flottant qui apparaisse partout (pages, sections et activités-mod) et qui appelle une activité Moodle, soit spécifique, locale et propre à une section, soit globale et d’application pour toutes les sections. La distinction locale vs globale devait se faire en fonction du contexte auto-détecté depuis le menu cours, et donc fonction de la section active dans le cours. L’affichage du CTA devait aussi pouvoir se faire par cours et pouvoir être associé à des conditions d’accès restrictives (durée écoulée depuis l’inscription, group membership…)
Humblement et peut-être un peu naïvement au départ, je me suis dit que c’était l’occasion d’essayer l’aventure d’un développement web php, mysql pour Moodle, avec une IA générative…
Sceptique ? Eh bien le bilan est plutôt assez bluffant !
Après avoir vérifié quelques avis, j’ai voulu essayer Copilot pour 365. Et je ne suis pas déçu. Le plugin local Moodle fait exactement ce que j’attendais et souhaitais, et ce au terme de 2 grosses semaines de boulot, auto-apprentissage compris, soit autant que le temps qu’aurait mis je pense un dev php junior.
Ce que j’en ai appris et retiens, et ce que je partage volontiers avec vous;
1 : Pas de fantasme ! Y a du taff !
Il ne suffit pas d’écrire 5 lignes de prompt et attendre que cela se passe en dégustant un espresso ou une tisane. Au final, il y aura eu une bonne vingtaine de releases, minor et major confondues, avant d’arriver à une Release Candidate stable.
2 : Exprimer clairement les objectifs et contraintes
Comme on s’y attendait, la pertinence, le détail et l’exactitude des prompts sont absolument déterminants pour un résultat qualitatif, ainsi que la capacité rédactionnelle utile pour exprimer clairement l’objectif. Parfois moins de mots mais les mots justes, et “Right to the Point”, c’est mieux.
Si les premiers prompts sont très longs pour bien poser le cadre, les suivants peuvent être plus courts et surtout réutilisables.
3 : Ordre et méthode
Un seul conseil ; documenter, classer et archiver vos releases avec soin et documenter les RFC’s de chaque release et les différences entres elles.
Si vous pouvez, utiliser un repository GitHub (ou autre), ce n’est pas indispensable, mais c’est mieux, pour exploiter et implémenter directement les diff (Copilot gère bien cela pour différencier le code modifié pour chaque fichier, pour chaque release, majeure ou mineure).
4 : Les limites de Copilot
Avant de parler des limites, notez que Copilot est plutôt qualifié pour construire une architecture globale en respectant les standards, mais aussi pour corriger et optimiser des morceaux de code ou des fonctions spécifiques.
Et pour les limites… ?
4.1 Conversations longues valent contradictions et hallucinations
Recommencer signifie sauver l’état de la session pour relancer une discussion avec le même background et l’historique. Ayez toujours un prompt prêt pour demander le moment venu un seed complet, format *.md (markdown) downloadable avec résumé, bilan, statut actuel de la réflexion et de la livraison, et éventuellement les sources.
4.2 Limites physiques
Immanquablement, à un moment Copilot vous annoncera brutalement que la conversation a atteint ses limites.
Basta, plus moyen d’ajouter la moindre ligne, mais surtout, plus moyen de demander un seed…
Cette limitation est due administrativement aux limites induites dans votre tenant Microsoft auquel est attaché votre agent Copilot 365.
Derrière ce quota, existent des contraintes et limites techniques liées au coût de traitement, c’est-à-dire l’usage de la mémoire et de la puissance de calcul, mais aussi à des garanties de qualité.
Une conversation trop longue entraîne de facto des dérives contextuelles dans le process de traitement de la question.
Dans le cas de Copilot la limite est globalement fixée à un maximum de 30 échanges par conversation et à une fenêtre de contexte de circa 4000 mots.
La première fois c’est surprenant… Une fois qu’on le sait on s’habitue et on s’organise…
A intervalles réguliers soit approximativement toutes les heures (comme il est difficile de compter le nombre d’échanges l’indicateur de temps est utile) ou lorsque vous constaterez que l’interface ne suit plus, que la latence au clavier devient importante… STOP !!! Et collez rapidement votre seed de clôture pour demander l’archive avant qu’il ne soit trop tard !
En effet, notez bien que relancer la conversation à partir de l’historique ne résout pas le problème. La conversation sera certes relancée, mais les performances redeviendront très rapidement désastreuses et la conversation inexploitable (en ce compris des surimpressions de blocs de texte à l’écran, ce qui rend la consultation quasiment impossible).
4.3 Gestion approximative des itérations
Last but not least, la plus grande faiblesse restera pour moi l’incapacité chronique à réaliser un vrai travail itératif et cumulatif.
Chaque nouveau RFC ou chaque nouvelle correction est susceptible de casser votre code préexistant… Ce qui fonctionnait parfaitement dans la version n-1 peut ne plus fonctionner dans la version courante.
D’où l’intérêt de versionner, classer et archiver vos releases… au cas où.
Certaines précautions d’usage peuvent limiter la casse, comme demander à l’IA de ne pas régénérer un package complet pour votre projet mais seulement les fichiers modifiés. Et même comme cela, vous devrez remettre votre ouvrage sur le métier. Une doc rigoureuse des releases vous aidera à faire plus court et plus efficace à chaque fois.
5 : Et les compétences techniques utiles ?
Les miennes sont plutôt limitées … ça vous donne un début de réponse.
Si vous savez lire le php, même si c’est en travers, et même si vous ne comprenez pas tout, ça peut le faire quand même. Un peu de CSS et de JS ça peut aider aussi.
Cependant, vous ne ferez pas l’impasse d’une excellente connaissance de la logique de fonctionnement de votre plateforme cible, soit Moodle dans le cas présent.
Ce qui recouvre et inclut ;
- les exigences en termes de structure des répertoires et des fichiers requis pour les plugins, et des éléments de syntaxe obligatoires,
- les méthodes d’enregistrement versionné des plugins,
- la gestion multilingue des interfaces (i18n),
- les fonctionnalités avancées d’administration (en ce compris la compréhension et la gestion des droits d’accès, capacités…),
- la gestion des caches serveurs (simples ou complexes, natives ou complémentaires, MUC, Redis…)
- et les techniques de troubleshooting ciblé, côté serveur et navigateur.
Un environnement de dev local en localhost est indispensable.
Honnêtement, un MAMP fait parfaitement l’affaire. Moodle met à disposition en download des MAMP complets pour Mac OS X (ou WAMP pour Windows) avec la version de Moodle souhaitée, php et les DB MySQL préinstallées.
Ayez sous la main un IDE basique et un outil de minification pour le JavaScript, si non inclus dans votre IDE (JSCompress par exemple).
Un accès à votre base de données MySQL inclue dans le MAMP, à sa console et des connaissances de base en SQL vous aideront à voir ce qui se passe au niveau DB, parce que parfois c’est là que ça coince ; problèmes de CRUD par exemple ou plus souvent de création ou d’update des tables et records (voir install.xml et upgrade.php dans le cas de Moodle).
Un accès à et une maîtrise minimale de GitHub est un plus.
Et enfin un navigateur, version développeur, avec une bonne console et quelques connaissances de base en troubleshooting console sont nécessaires aussi. Perso, je suis fan de Chrome et de sa console. Mais no panic, ici encore Copilot te dira très exactement ce que tu dois faire en console et le code que tu dois y coller et comment interpréter les résultats.
Conclusions
De cette expérience de #vibecoding, je retiendrai surtout, l’élargissement du champ des possibles.
Dans un schéma d’apprentissage traditionnel de coding, jamais je ne me serais lancé dans un tel projet, et surtout jamais je ne serais parvenu au résultat escompté dans un délais aussi court.
Je n’aurais eu d’autres choix que de renoncer… ou de sous-traiter le travail et d’engager le budget nécessaire… Or sur certains projets ou pilotes le budget est parfois limité…
Bien sûr, vous n’aurez pas les félicitations du jury pour la qualité du code, pas toujours optimisé, mais vous obtiendrez à moindres frais une version stable de la ou des fonctionnalités souhaitées.
Et puis surtout c’est FUN 🙂
That’s All Folks !
Mais si vous voulez échanger sur le sujet, je suis partant.
En savoir plus ? Des questions ?
Vous souhaitez en savoir plus, laissez-nous un message.
Pour connaître toute notre actualité, inscrivez-vous à notre newsletter.
Merci de nous avoir lu.
Stay Tuned !
