Éditeur en ligne “bac à sable”

Cette réalisation a été menée durant la troisième année du BUT Informatique, dans le cadre d’une SAÉ longue consacrée au développement avancé. Elle correspond à une période où les projets n’étaient plus seulement évalués sur leur faisabilité technique, mais aussi sur leur cadrage, leur organisation, leur niveau d’exigence et leur capacité à démontrer une logique de produit cohérente.

Le projet a occupé une place importante dans mon parcours, car il m’a confronté à un sujet plus ambitieux que les développements académiques habituels : un éditeur de code en ligne capable d’exécuter du code dans un environnement isolé, avec des enjeux de sécurité, d’expérience utilisateur, d’architecture web et de coordination d’équipe. Il m’a aussi permis de découvrir Angular dans un contexte concret de production collective, ce qui a renforcé son intérêt dans mon projet professionnel orienté développement web.

Sandkasten est une application web de type playground permettant d’écrire, modifier, enregistrer et exécuter du code directement depuis un navigateur, sans installation locale. L’idée était de proposer un environnement en ligne plus souple qu’une exécution locale improvisée, avec un éditeur moderne, un système de comptes, la sauvegarde de travaux, une logique de partage et, à terme, la prise en charge de plusieurs langages de programmation.

Le projet reposait sur une architecture répartie entre plusieurs briques : une interface web développée avec Angular, une couche de communication et d’orchestration côté backend avec Bun, des mécanismes d’exécution isolée pour éviter qu’un code malveillant ne compromette la machine hôte, et une base SQLite pour gérer les comptes et les travaux enregistrés. La logique générale visait à construire une preuve de concept crédible, progressive et suffisamment robuste pour valider la viabilité technique du produit.

Le sujet est né d’un choix libre de projet, que l’équipe a ensuite présenté à plusieurs enseignants avant d’obtenir l’encadrement de M. Guinaldo. Cette étape de démarchage a donné au projet une dimension plus entrepreneuriale que la moyenne des SAÉ, puisqu’il a fallu défendre l’idée, démontrer son intérêt technique et convaincre qu’elle méritait un suivi.

Les objectifs étaient à la fois fonctionnels, techniques et pédagogiques. Il fallait proposer un éditeur de code en ligne, exécuter le code dans un environnement maîtrisé, construire un système de comptes et de sauvegarde, préparer le support de plusieurs langages, réfléchir à la collaboration en ligne et monter en compétence sur des technologies nouvelles comme Angular, Bun, les mécanismes de conteneurisation et les outils de qualité logicielle.

Les principaux enjeux concernaient la sécurité de l’exécution, la scalabilité, l’intégration entre les différentes briques techniques, la qualité du code et la capacité du groupe à maintenir une progression cohérente sur un sujet ambitieux. Les risques identifiés tenaient autant à la difficulté du cadrage progressif qu’à l’apprentissage simultané de nouvelles technologies, à la complexité des interactions entre front, API et exécution du code, et aux contraintes d’organisation liées aux rythmes de travail différents au sein de l’équipe.

J’ai participé à la phase de cadrage initial, pendant laquelle nous avons défini le périmètre du produit, comparé les technologies, voté certains choix structurants et adopté une logique de Proof of Concept. Cette approche nous a permis de viser d’abord une base fonctionnelle crédible avant d’ajouter des fonctionnalités plus avancées, ce qui a été décisif pour garder le projet réalisable dans le temps disponible.

Sur le plan technique, cette réalisation m’a demandé de prendre en main Angular, que je n’avais encore jamais utilisé. Cette montée en compétence a représenté une part réelle du projet, car l’équipe a consacré une partie importante du début de SA à apprendre le framework avant de pouvoir structurer correctement l’interface et ses composants. Dans mon cas, cette découverte a été directement utile pour la suite de mon parcours, car elle a renforcé mon intérêt pour les frameworks front-end modernes et m’a donné une première expérience concrète de leur usage en équipe.

Ma contribution a porté plus particulièrement sur les sujets liés aux comptes utilisateurs, à la base de données SQLite, à l’internationalisation et à la présentation du projet en soutenance. J’ai travaillé sur la logique de gestion des comptes, avec stockage des identifiants, gestion des travaux enregistrés, prise en compte d’un lien de partage, hashage salé des mots de passe avec bcrypt, création de session et authentification entre les requêtes. J’ai également participé à la mise en place de l’internationalisation via ngx-translate, pour permettre le basculement entre français et anglais au sein de l’interface.

Au-delà de ces fonctionnalités, j’ai aussi contribué à la structuration du projet et à son suivi quotidien. Cela passait par les réunions d’équipe, les points d’avancement, la synchronisation sur Discord, l’usage du Gantt, du Kanban, des branches partagées et des demandes d’ajout relues par d’autres membres du groupe. Cette partie a renforcé ma capacité à travailler sur un projet où la technique seule ne suffit pas, et où la qualité dépend aussi de la clarté du suivi et de la régularité des échanges.

Le projet a été mené par une équipe de cinq étudiants : Clément Fréville, Matis Mazingue, Colin Frizot, Bastien Ollier et moi-même. Le suivi reposait sur un double encadrement, avec M. Guinaldo pour l’accompagnement technique et Mme Chatti pour la gestion de projet.

L’organisation cherchait un équilibre entre répartition claire des responsabilités et polyvalence. Chacun disposait de tâches identifiées, mais l’objectif n’était pas d’isoler les membres sur une seule brique technique : il fallait aussi progresser collectivement, relire le travail des autres, se synchroniser régulièrement et garder une vision d’ensemble du produit.

Les interactions ont joué un rôle déterminant dans la réussite du projet. Nous avons utilisé Discord pour la communication continue, Google Drive pour centraliser les documents, CodeFirst pour partager le code et suivre les demandes d’ajout, WakaTime pour le suivi du temps, ainsi qu’un Kanban et un Gantt pour piloter l’avancement. Nous avons également eu recours à la relecture croisée et ponctuellement au pair programming, notamment pour compenser des écarts de niveau sur certaines technologies et fluidifier l’intégration des contributions.

De mon côté, j’ai particulièrement retenu l’importance des résumés de séance, des retours oraux simples et des points d’avancement fréquents. Cette pratique a été utile notamment quand certains membres n’avaient pas exactement les mêmes créneaux de travail, ce qui rendait nécessaire un effort supplémentaire de synchronisation.

Le projet a abouti à une version 1.0 livrée dans les délais, avec les fonctionnalités jugées prioritaires pour cette étape. L’équipe a réussi à relier les principales briques de l’application, à démontrer la faisabilité d’un éditeur de code en ligne sécurisé et à produire une base technique suffisamment solide pour valider le concept. La date jalon de la version 1.0, fixée au 5 juin 2024, a bien été tenue.

Pour le groupe, cette réalisation a permis de produire un projet ambitieux, cohérent et techniquement crédible, en combinant interface web, gestion de comptes, exécution isolée, démarche PoC et pipeline de qualité avec relecture, construction automatique, tests, ESLint, Clang-Tidy, SonarQube, Jasmine et Karma.

Pour moi, le résultat le plus important a été la progression sur plusieurs plans à la fois : développement web, prise en main d’Angular, structuration d’un travail collectif, communication d’avancement et articulation entre contribution technique et qualité globale du produit. Cette réalisation m’a aussi aidé à mieux relier la logique de projet de la SA à des situations rencontrées en entreprise, notamment autour du PoC et de l’intégration progressive de nouvelles fonctionnalités.

Même si une version fonctionnelle a été produite, plusieurs pistes d’évolution restaient ouvertes à la fin du projet. Parmi les principales figuraient les tests de charge, la gestion de plusieurs fichiers, l’ajout de bibliothèques, l’extension à d’autres langages, le déploiement, ainsi que le renforcement de certaines fonctionnalités de collaboration en temps réel.

Avec du recul, Sandkasten apparaît surtout comme une base solide et crédible, plus qu’un produit totalement finalisé. Le projet a démontré qu’une démarche itérative, mêlant PoC, validation régulière, outillage de qualité et ajustement progressif du périmètre, pouvait transformer une idée ambitieuse en application cohérente.

Cette réalisation a été particulièrement formatrice, car elle m’a placé dans une situation proche d’un vrai projet produit : un sujet ambitieux, un cadrage évolutif, des technologies nouvelles à maîtriser et un niveau d’exigence plus élevé que sur des travaux plus courts. L’apprentissage d’Angular en parallèle du développement réel a représenté un effort important, mais c’est aussi ce qui a rendu l’expérience très utile pour la suite de mon parcours.

Le principal enseignement que j’en retiens concerne l’articulation entre technique, organisation et qualité. Un projet avancé ne progresse pas seulement grâce à de bonnes idées techniques : il avance aussi grâce à des objectifs clairs, des échanges réguliers, des retours bien formulés, une documentation suffisante et une organisation qui permet au groupe de rester aligné malgré les imprévus.

Si ce projet devait être repris aujourd’hui, je formaliserais plus tôt certaines responsabilités, je renforcerais les tests sur les cas limites, et je documenterais plus vite les choix structurants pour faciliter l’intégration et l’évolution du produit. Ce recul critique est important, parce qu’il montre que la réussite d’un projet ne se mesure pas seulement à ce qui a été livré, mais aussi à ce qu’il apprend sur la manière de mieux concevoir le suivant.