En tant que développeur principalement orienté vers R, je m’attache à suivre les bonnes pratiques de développement : écrire une documentation utilisateur claire avec des articles et des exemples; créer des tests robustes; et automatiser les processus de vérifications et de déploiements avec des workflows CI/CD. Ces habitudes m’ont permis de construire des projets fiables et maintenables, mais je me suis demandé : ces pratiques sont-elles transférables si je m’aventure dans un autre écosystème, comme Node.js ?
Pour y répondre, je me suis lancé un défi personnel : créer un site web entièrement en Node.js et JavaScript, tout en profitant de l’occasion pour tester GitHub Copilot Workspace comme principal assistant de développement. Mon objectif était de voir si Copilot pouvait me guider de A à Z, en faisant comme si je n’y connaissais rien. Et de tester l’hypothèse selon laquelle, même sans expertise approfondie dans un langage ou framework, on peut réussir en s’appuyant sur des pratiques solides et les bons outils.
Et ça tombait bien, car j’avais un projet concret en tête : afficher les principaux parcours de marche autour de ma commune sur une carte interactive, afin de les partager avec les membres de mon association. Je voulais également rendre le système facile à mettre à jour, en ajoutant de nouveaux parcours directement depuis mon smartphone à la fin de chaque rando, sans devoir modifier le code du site manuellement.
Le résultat ? Un site web en ligne sur GitHub Pages, automatiquement mis à jour grâce aux traces GPX deposées sur mon Google Drive : https://statnmap.github.io/gpx-traces-website/. Cet article partage les étapes de ce projet, les leçons tirées et, surtout, comment mes compétences en développement avec R m’ont permis de mener à bien cette aventure.
Figure 1: Capture d’écran du site web actuel
Index
Les bonnes pratiques en R comme base solide
De mon côté, tout projet R est un package documenté, testé, et versionné. Ce n’est pas pour rien que j’ai développé le package {fusen} : un outil qui permet de créer un package R directement à partir d’un fichier Rmarkdown. L’objectif est clair : encourager et simplifier l’intégration de la documentation et des tests dans les projets R. Cette démarche garantit que chaque projet reste organisé, compréhensible, et surtout, maintenable sur le long terme.
Figure 2: Processus fusen : d’un simple Rmarkdown à un package R complet
Ces bonnes pratiques, que j’applique systématiquement, se décomposent en trois grands axes :
Documentation
Pour moi, chaque fonction doit être accompagnée d’une documentation utilisateur claire et complète. Avec{roxygen2}, cette documentation est directement intégrée au code, ce qui garantit une mise à jour simple et rapide dès qu’une modification est effectuée. De plus, la rédaction d’articles détaillés sous forme de vignettes{rmarkdown}permet d’offrir une vue d’ensemble du projet ou des exemples d’utilisation concrets.Tests unitaires
Les tests ne sont pas une option : ils sont essentiels pour s’assurer que tout fonctionne comme prévu, aujourd’hui et demain. Avec{testthat}notamment, je m’assure de couvrir chaque fonctionnalité critique. Les tests servent aussi de documentation implicite : ils montrent comment les fonctions doivent se comporter et aident à identifier rapidement les régressions en cas de changement.Pour illustrer leur importance, je pourrais presque créer un indicateur : “X jours depuis le dernier jour où j’ai été sauvé par un test unitaire”. Spoiler alert : ce nombre reste généralement très bas… Les tests sont là pour attraper les erreurs avant qu’elles ne deviennent des problèmes, et croyez-moi, ils font leur travail !
Automatisation avec CI/CD
Grâce à des workflows CI/CD, chaque modification du code est automatiquement vérifiée : les tests sont exécutés, la documentation est générée, et le projet est validé. Cette automatisation n’est pas seulement un gain de temps : elle garantit également une qualité constante, quel que soit le nombre de contributeurs ou de changements apportés. Elle permet aussi de tester le code dans des environnements variés : différents systèmes d’exploitation, plusieurs versions de R, ou encore des configurations spécifiques.Pour un projet web comme celui-ci, l’intégration continue va encore plus loin en déployant automatiquement les modifications sur le site en ligne. Cela réduit considérablement les risques d’erreurs humaines et offre un processus de mise à jour fluide et sécurisé. Résultat : un gain de sérénité et une maintenance simplifiée, particulièrement précieux pour un projet en évolution régulière.
Ces pratiques, ancrées dans mon travail avec R, ne se limitent pas à un langage ou un outil. Ce sont des principes universels de développement logiciel, et ce projet en Node.js était l’occasion parfaite de tester leur efficacité dans un environnement complètement différent.
Une phase de conception indispensable
Lorsque je me suis lancé dans ce projet de création d’un site web avec Node.js et JavaScript, j’ai commencé par une étape essentielle : la conception centrée sur les besoins utilisateurs et les critères de succès. Avant d’écrire la moindre ligne de code, il était crucial de définir clairement :
Quels étaient les besoins principaux des utilisateurs ?
En tant qu’utilisateur principal de l’application, j’avais deux besoins principaux :
1. Visualiser facilement les parcours existants sur une carte interactive depuis mon smartphone.
2. Télécharger la trace GPX de mon choix sur mon smartphone, afin de l’importer dans mon application de randonnée préférée (comme OutdoorActive ou Komoot), et commencer directement une rando quand je n’ai pas préparé de parcours en amont.
Quels critères permettraient de considérer le projet comme un succès ?
Le site devait être accessible publiquement, fonctionnel sur un smartphone, et facilement maintenable. En plus de répondre aux besoins ci-dessus, il devait permettre d’ajouter facilement de nouveaux parcours, idéalement via une solution automatisée ne nécessitant pas de manipulation complexe.
Cette réflexion en amont m’a permis de clarifier les objectifs :
- Permettre une visualisation claire et interactive des parcours disponibles.
- Offrir un moyen simple de télécharger les fichiers GPX pour chaque parcours.
- Faciliter l’ajout de nouveaux tracés via une automatisation, rendant le système adaptable sans effort.
L’expérience avec GitHub Copilot Workspace pour la conception technique
Après la définiton de la vision utilisateur, Copilot Workspace prend le relais pour transformer mes besoins en suggestions concrètes de développement. Pour pousser l’expérience à son maximum, j’ai abordé le projet comme si je n’avais aucune expertise en développement web.
Un produit minimal fonctionnel (MVP)
Ma première demande de “brainstorm” était volontairement plutôt simple afin d’obtenir rapidement un produit minimal fonctionnel (MVP) : Par habitude, je lui parle en anglais. Vous pouvez toujours lui parler en français, il comprendra, mais il répondra en anglais.
A static website on github pages, updated through github actions.
The website :
- uses a list of gpx files stored in the repository as input,
- shows the gpx traces on a interactive map
- allows the users to click traces on the map to download them
- each trace has a category "sec", "humide", "boueux", allowing for selection of traces shown on the map
It is ok if the gpx traces need a preparation during website pre-build.
En français:
Un site web statique sur GitHub Pages, mis à jour via GitHub Actions.
Le site web :
- utilise une liste de fichiers GPX stockés dans le dépôt comme entrée,
- affiche les traces GPX sur une carte interactive,
- permet aux utilisateurs de cliquer sur les traces sur la carte pour les télécharger,
- chaque trace a une catégorie "sec", "humide", "boueux", permettant de sélectionner les traces affichées sur la carte.
Il est acceptable que les traces GPX nécessitent une préparation lors de la pré-construction du site web.Idées de développement et génération de code
Copilot Workspace a alors proposé plusieurs “idées” de développement, correspondant à des stratégies possibles à combiner pour répondre à mes besoins. À cette étape, il était possible de choisir :
- Générer uniquement le plan, afin de clarifier les grandes étapes du projet.
- Générer directement le code complet à partir du plan, pour aller plus vite.
Figure 3: Mes instructions sur la gauche. Le résultat du brainstorm sur la droite
J’ai d’abord choisi de générer un plan avant de passer au code complet.
Figure 4: Le plan avec les actions à réaliser sur la gauche. Le code généré automatiquement sur la droite.
Ensuite, plusieurs options se sont ouvertes à moi :
- Demander une révision du plan (“Brainstorm”) pour ajouter des idées ou clarifier certains points.
- Réviser le code généré (“Revise”) si des optimisations étaient nécessaires.
- Modifier le code moi-même, grâce à mes compétences en développement.
Un développement fluide et guidé
Lorsque j’étais satisfait du résultat, j’ai pu créer directement un dépôt GitHub privé depuis Copilot Workspace, générer les commits et pousser le code sur GitHub.
Pour les évolutions du projet, j’ai lancé de nouvelles sessions de brainstorming pour :
- Ajouter des fonctionnalités ou des améliorations.
- Corriger des erreurs détectées lors de l’intégration continue.
Copilot Workspace a proposé d’apporter les modifications sous forme de Pull Requests, facilitant un workflow structuré et maintenable.
Exemples concrets
Parmi les propositions de Copilot Workspace :
Une structure classique pour une page web, avec des dossiers dédiés aux scripts JS, bien séparés selon les fonctionnalités : préparation des données d’un côté, interactivité de la carte de l’autre.
Un workflow de CI/CD, avec l’exécution des étapes de préparation des données, de construction du site, et de déploiement sur GitHub Pages.
Une assistance dans l’écriture du script de manipulation des fichiers GPX, pour les préparer à l’affichage sur la carte, ainsi que dans la création des composants de filtres sur la carte.
Une solution simple pour gérer les téléchargements des fichiers GPX, permettant aux utilisateurs de récupérer facilement les tracés pour leur application de randonnée.
Une aide précieuse pour la correction du workflow CI/CD, en m’assistant dans la gestion des erreurs rencontrées lors de la préparation des données et de la construction du site (cf. capture d’écran).
Figure 5: Plusieurs sessions de brainstorm indépendantes pour fixer les différentes erreurs de CI/CD rencontrées.
Leçons tirées de l’usage de Copilot Workspace
Cette expérience m’a rappelé l’importance de bien définir les besoins des utilisateurs dès le départ en langage naturel. Une conception claire et centrée sur les attentes facilite ensuite le développement technique, notamment avec des outils comme GitHub Copilot Workspace. Cela prouve qu’un projet bien réfléchi dès la base permet de gagner en efficacité et en qualité tout au long du processus.
Cependant, il ne faut pas négliger les bonnes pratiques de développement comme la documentation, les tests et l’automatisation. Ces pratiques restent des piliers solides, quel que soit le langage ou le framework utilisé, et permettent d’avancer sereinement sur un tel projet, en favorisant la qualité à chaque étape.
1. Copilot Workspace est une aide pour les Tech Lead
Copilot Workspace n’est pas un simple générateur de code pour rédiger ou déboguer un fichier en cours, c’est une aide précieuse pour la maîtrise d’oeuvre. Non seulement il propose des idées d’approche pour répondre à vos besoins, mais il permet également de générer, dans la même interface, la totalité des dossiers et fichiers au même endroit et en même temps. C’est un gain de temps considérable pour la mise en place d’un nouveau projet notamment. De plus, comme il est entièrement lié à votre dépôt GitHub, vous pouvez envoyer vos modifications directement en ligne. Il est totalement complémentaire de Copilot dans votre éditeur préféré.
2. Relier avec les demandes de fonctionnalités
J’aurais pu aller encore plus loin en rédigeant mes besoins sous forme d’issues GitHub, avec des user stories bien structurées et des critères de succès. Je l’ai testé sur deux issues pour voir. Ces issues peuvent être ouvertes directement dans l’espace Workspace, générant automatiquement des “brainstorms”. Lier ces issues aux messages de commits améliore également la traçabilité du projet. Pour suivre l’évolution du projet avec d’autres développeurs, c’est un atout précieux.
Figure 6: Capture d’écran d’une issue GitHub avec le bouton pour l’ouvrir directement dans Workspace
3. L’importance du CI/CD dès le départ
Dès le début, j’ai volontairement forcé Copilot à mettre en place un workflow CI/CD. Même si je n’ai pas eu besoin de plonger profondément dans le code JavaScript, j’ai pu avoir un code fonctionnel simplement en lui demandant de corriger les erreurs rencontrées dans les PR : “Voici le message d’erreur du CI, peux-tu m’aider à le corriger ?”.
Le gain de temps a été considérable, surtout pour un langage que je maîtrise moins. Ce choix m’a confirmé une vérité que je connais déjà avec mes projets R : les erreurs liées au CI/CD sont souvent les plus chronophages et complexes à déboguer, car on ne pense pas toujours aux spécificités d’un OS vierge ou différent de son poste de travail…
Je ne suis donc pas surpris qu’une IA galère à proposer un workflow CI/CD fonctionnel du premier coup. Cependant, elle m’a été d’une grande aide pour corriger ces erreurs et rendre le pipeline fiable.
4. Documentation et tests : ne rien laisser de côté
Par défaut, Copilot ne m’avait pas proposé de tests unitaires ni de documentation des fonctions. Grâce à mes habitudes de développement avec R, j’ai pris soin d’intégrer rapidement des tests unitaires et end-to-end pour m’assurer que les sorties des fonctions JS étaient cohérentes avec les besoins utilisateurs.
De la même manière, mon besoin de documentation (hérité de {roxygen2}) m’a conduit à lui demander de documenter les fonctions et de générer un site de documentation, tel {pkgdown}, avec JSDoc : https://statnmap.github.io/gpx-traces-website/docs/. Cette démarche a permis de rendre le projet plus robuste et maintenable.
Figure 7: Page web de documentation JSDoc du projet
5. Copilot apprend de vos pratiques
Une fois les tests unitaires, la documentation des fonctions et le remplissage du README mis en place, Copilot a continué de les proposer pour chaque évolution du projet. Cela fonctionne aussi avec GitHub Copilot quand vous l’utilisez dans VSCode.
D’ailleurs, pour Copilot (tout court), travailler dans un fichier Notebook unique comme avec {fusen}, où la doc, le code et les tests sont centralisés, simplifie énormément le travail de l’IA pour l’aide à la génération du code… Moi j’dis ça, j’dis rien !
Notez que ça fonctionne aussi avec les messages de commit. Dans Workspace, lorsque vous êtes prêt à commiter, Copilot peut vous proposer la génération automatique du message. De même, VSCode en local propose cette fonctionnalité. Si vous utilisez le “conventional commit”, vous aurez besoin de modifier le premier message, mais en théorie, les suivants conserveront vos habitudes.
6. Gérer les librairies Node
Lorsque vous ajoutez des librairies Node.js à votre projet, Copilot ne les gère pas totalement de manière automatique. Il faudra parfois les ajouter manuellement dans le fichier package.json et surtout les installer avec npm install.
La bonne nouvelle, c’est que Copilot Workspace propose souvent la commande adéquate dans la dernière section “Commands” des étapes du projet. Vous pouvez l’exécuter directement dans le terminal intégré, en cliquant sur l’icône d’exécution à côté de la commande. Cela vous évite de rapatrier le projet sur votre machine locale juste pour installer les librairies.
Figure 8: La section ‘Commands’ liste les commandes à exécuter manuellement, et cela peut s’exécuter directement dans le Terminal de Copilot Workspace
Gestion des versions : vigilance requise
Un point à surveiller : la gestion des versions des dépendances. Copilot ne propose pas toujours la version la plus récente dans package.json. De plus, il ne suggère pas de mise à jour des dépendances ni de résolution des conflits de versions. Vous devrez donc être vigilant sur ce point.
Heureusement, l’intégration continue vous alertera rapidement si une dépendance pose problème ! Et pour anticiper avant même le commit, pensez à utiliser le Terminal de Copilot Workspace pour lancer des commandes comme npm audit.
Lancez-vous !
Les langages de programmation peuvent sembler tous différents, mais ils se ressemblent. Les développeuses et développeurs s’inspirent les uns des autres et font évoluer leur langage en fonction de ce qui cool à côté. Bien sûr, en changeant de langage, vous devrez apprendre de nouvelles syntaxes, de nouvelles librairies, de nouvelles façons de faire. Mais les bonnes pratiques de développement sont universelles.
Ce projet en Node.js m’a permis de le vérifier. En m’appuyant sur mes habitudes acquises avec R, j’ai pu concevoir, développer et déployer un site web complet sans (presque) écrire une seule ligne de code. Copilot Workspace m’a guidé à chaque étape, mais c’est bien mes compétences et habitudes de développement qui ont fait la différence.
Je vous encourage donc à explorer de nouvelles technologies, à sortir de votre zone de confort, tout en gardant en tête que les bases solides que vous avez acquises avec R ou tout autre langage sont transférables. Les outils évoluent, les langages changent, mais les bonnes pratiques restent. Et c’est ce qui fait la force de tout développeur ou développeuse.
Vous pouvez retrouver :
- le code source du projet sur GitHub : gpx-traces-website.
- le site web en ligne : https://statnmap.github.io/gpx-traces-website/.
- la documentation générée avec “JSDoc” avec le CI : https://statnmap.github.io/gpx-traces-website/docs/.
Et vous ? Quelle a été votre expérience avec GitHub Copilot Worksapce ou un autre assistant de développement ? Quels sont vos conseils pour réussir un projet dans un nouveau langage ou framework ? Partagez vos retours et vos astuces dans les commentaires !
Citation :
Merci de citer ce travail avec :
Rochette Sébastien. (2025, janv.. 27). "Créer un site web en Node.js avec GitHub Copilot Workspace, à l'aide des bonnes pratiques de développement en R". Retrieved from https://statnmap.com/fr/2025-01-27-creer-un-site-web-en-node-js-avec-github-copilot-workspace/.
Citation BibTex :
@misc{Roche2025Créer,
author = {Rochette Sébastien},
title = {Créer un site web en Node.js avec GitHub Copilot Workspace, à l'aide des bonnes pratiques de développement en R},
url = {https://statnmap.com/fr/2025-01-27-creer-un-site-web-en-node-js-avec-github-copilot-workspace/},
year = {2025}
}