Techniques Informatiques – Site CAS Pierre-Ange Delbary-Rouillé – Vici56

CAS WEB – 14.7 – CONCLUSION

pierre.ange.delbary.rouille@gmail.com — Sat, 26 Apr 2025 10:25:04 +0000

CONCLUSION

Voilà ! La partie « installation d’un blog sur un serveur Web » est désormais terminée.

Si vous consultez d’ailleurs ce tutoriel, c’est que le serveur web tourne toujours, car c’est celui que j’ai mis en œuvre. Vous l’avez compris, il servira aussi à mes sœurs…

Tout au long de ce Tutoriel, nous avons donc :

Démystifié un certain nombre de concepts,
Acheté un nom de domaine,
Loué un Serveur Privé Virtuel,
Configuré le nom de domaine pour qu’il pointe vers le serveur,
Mis en œuvre Docker sur le serveur pour faire tourner des conteneurs,
Mis en œuvres des conteneurs de :
- Base de Données,
- Serveur Web,
- Système de Blog.
Mis en œuvre des outils de certification de nom de domaine,
Mis en œuvre des outils d’administration pour simplifier la gestion du serveur.

J’allais oublier le « presque » principal : j’ai rédigé cette longue liste d’articles de Blog.

J’espère qu’il vous sera utile et que vous serez nombreux à vous exprimer sur Internet à travers un beau Blog !

Evaluation des Objectifs :

Au travers de ce CAS, je m’étais fixé les objectifs d’apprentissage suivants :

Identifier mes points forts et développer certaines aptitudes : effectivement, au départ de ce CAS, j’étais assez vierge de connaissances sur tout ce qui tournait autour des serveurs Web. Ici, pas besoin de compétences en maths ou autre : juste savoir faire preuve de logique et d’attention pour bien comprendre les mécanismes de fonctionnement d’un serveur. Je suis content d’avoir appris et compris à travers la lecture de documentations ou d’autres articles de Blog. Mon point fort dans tout cela : avoir été capable de trouver les bonnes sources d’information, et avoir parfois l’intuition qui change tout ! Mes aptitudes sont sans conteste le fait de savoir me remettre en question quand je suis persuadé que ce n’est pas moi qui ait mal procédé mais le concepteur du logiciel .
Démontrer que des défis ont été relevés et qu’ils sont à l’origine de nouvelles compétences : finalement, le défi était plus élevé que je ne m’y attendais. Pour être franc, en me lançant dans ce projet, je me disait qu’il allait passer comme une lettre à la poste : c’était sans considérer que les choses sont « parfois » un peu plus compliquées qu’elles n’y paraissent… Ma fierté, c’est d’avoir été jusqu’au bout même quand j’étais un peu largué.
Montrer une aptitude à initier et planifier une expérience CAS : pour le coup, au niveau de l’initiation du projet je pense avoir été très efficace. Mais en ce qui concerne la planification, je dois avouer que j’ai été très vite dépassé dans la mesure où je n’avais pas planifié assez de plages de temps pour les problèmes éventuels. Je pense que ce projet qui devait s’étaler sur une semaine a en réalité duré le triple… pas forcément brillant, mais le jeu en valait la chandelle.
Faire preuve d’engagement et de persévérance : je m’étais engagé à produire une série d’articles qui permettrait à tout un chacun de monter son propre site Web. Le pari est réussi, et cette longue série d’articles en est la preuve. Cependant, j’ai parfois été découragé par les « micro » problèmes qui ont entaché mon parcours. C’était en partie lié à ma méconnaissance de l’environnement des serveurs, mais j’ai failli abandonner. Un petit coup de pouce externe m’a remis en selle, et ceci m’a permis de continuer pour enfin finir ce tutoriel.

CAS FUSÉE – 15 – Synthèse et perspectives

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 16:05:03 +0000

Synthèse et perspectives

Lorsque j’ai commencé ce projet en décembre 2023, je n’imaginais pas à quel point il allait évoluer. Ce qui n’était au départ qu’une curiosité pour les fusées et un exercice de programmation s’est transformé en un projet complet mêlant physique, mathématiques, développement web, gestion de données, sécurité informatique et, finalement, service à une communauté.

Tout au long du processus, j’ai découvert et approfondi de nombreuses compétences :

scientifiques, en étudiant les forces, les équations différentielles et les méthodes de résolution numérique ;
techniques, en apprenant à coder en JavaScript, à développer une API en PHP avec Symfony, et à gérer un projet logiciel structuré ;
organisationnelles, en structurant mon code, en versionnant mon travail, et en documentant chaque étape ;
humaines, en découvrant que mon travail pouvait servir à d’autres, et en adaptant mon projet à cet objectif.

Ce projet a été un véritable parcours d’apprentissage autonome, mais aussi un espace de création personnelle. J’ai souvent dû chercher des réponses par moi-même, tester, corriger, repartir de zéro. Cela m’a appris à persévérer, à mieux planifier, et à faire des choix techniques en fonction d’objectifs réels.

Mais au-delà de l’apprentissage, ce que je retiens surtout, c’est l’évolution du sens du projet. Je ne l’ai pas conçu pour les autres au départ, mais c’est en voyant leur intérêt que j’ai compris qu’il pouvait dépasser sa fonction initiale. Ce changement de perspective est probablement la partie la plus marquante de cette expérience.

Quant à l’avenir, plusieurs pistes d’évolution sont possibles :

améliorer l’interface pour qu’elle soit plus intuitive, plus complète, voire accessible sur mobile ;
intégrer des données réelles, par exemple des paramètres de fusées existantes (Ariane, Falcon…) ;
ajouter un moteur physique 2D ou 3D, pour simuler des vols obliques ou orbitaux ;
proposer une version éducative avec des modules de découverte (quiz, tutoriels…) ;
ouvrir le projet à la contribution d’autres élèves ou développeurs via GitHub.

A l’heure où j’écris cet article, nous sommes en Avril 2025. Cela fait près d’un an et demi que j’ai initié ce méga projet dont j’avoue être fier et sur lequel j’ai planché des nombreuses heures : je n’ai pas réellement calculé combien de temps il m’a pris, mais j’estime être à environ 400 heures de travail, IA comprise.

Je ne sais pas encore jusqu’où j’irai dans ces directions, mais ce projet m’a donné une confiance nouvelle dans ma capacité à apprendre et à construire quelque chose de cohérent, utile, et techniquement abouti.

Synthèse

Ce projet m’a permis de combiner mes intérêts pour les sciences, l’informatique et la pédagogie. Il a évolué bien au-delà de ce que j’avais prévu au départ, m’offrant une expérience complète de conception, de développement, d’analyse et de partage. Il m’a aussi permis de vivre concrètement l’esprit du CAS : créativité, activité et service. Je repars avec des compétences nouvelles, une vision plus large, et l’envie de continuer à créer et à apprendre.

Evaluation des Objectifs :

Au travers de ce CAS LONG, je m’étais fixé les objectifs d’apprentissage suivants :

Identifier mes points forts et développer certaines aptitudes : ce projet a été une immense imertion dans le monde de l’informatique et du développement logiciel en particulier. Pour y parvenir, j’ai dû :
1. Apprendre plusieurs langages (html, javascript, php, docker)
2. Me familiariser avec des concepts informatiques inconnus (bases de la programmation, classes, api)
3. Implémenter des principes solides et rigoureur
Démontrer que des défis ont été relevés et qu’ils sont à l’origine de nouvelles compétences : JAMAIS je n’aurais imaginé être capable d’atteindre un tel niveau. Je pense raisonnablement avoir le niveau d’un développeur junior, et mes compétences pourraient me permettre d’ores et déjà d’aborder le monde de l’emploi en freelance ou non.
Montrer une aptitude à initier et planifier une expérience CAS : j’ai dû étudier les principes de réflexion qui amènent à la conception d’un projet de A à A. Ceci a impliqué l’étude du déroulement des phases d’un projet, de conception de base, à sa mise en œuvre à une échelle professionnelle. Des choses que l’on n’apprend qu’en suivant des cours, ou en s’impliquant à fond sur le projet et les méthodes.
Faire preuve d’engagement et de persévérance : au début, ce projet qui n’était qu’un ‘side-project’ m’a amené à le faire évoluer vers un résultat quasi professionnel, et donc m’impliquer profondément. La persévérance a été nécessaire, même si j’ai pu faire appel à des personnes qui étaient « du métier ». J’ai eu des phases de découragement, mais j’ai su me remettre en selle et parvenir à mes fins.
Démontrer des compétences et reconnaître les bénéfices du travail en collaboration : j’ai pu échanger avec des personnes qui ont trouvé un intérêt dans mon projet et qui m’ont donné des pistes de réflexion ; notamment le fait de mettre ce projet à disposition de la communauté et d’en faire un projet interactif dans le sens ou la communauté peut s’y connecter et développer ses propres algorithmes. Le fait d’avoir mis mon premier projet sur Github est une grande satisfaction.
Démontrer son engagement dans des questions d’importance mondiale : cela rejoint le point précédent dans la mesure où la porté de ce projet dépasse le cadre scolaire : la terre entière, de par le fait que le projet est sur Github, peut y accéder et les personnes intéressées peuvent développer leurs propres modèles. Une IMMENSE satisfaction !
Reconnaître et réfléchir à l’éthique des choix et des actions : ce CAS m’a fait réfléchir sur l’importance des fusées. Je dois avouer cependant que je n’ai pas vraiment eu l’occasion de pouvoir implémenter quelque chose qui aurait rapport à l’éthique du monde des fusées. Mais je me suis sincèrement penché sur la mienne, et sur ce que je devais au monde : prouver qu’un élève d’IB pouvait produire un logiciel viable, open source, gratuitement, qui peut-être, pourrait servir l’éducation : ce fut ma ligne de conduite, ma ligne étique ; pouvoir rendre service !

CAS FUSÉE – 14 – Vers l’extérieur – Une dimension sociale inattendue

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 16:01:10 +0000

Partie 4 - Vers l’extérieur - Une dimension sociale inattendue

Lorsque j’ai commencé ce projet, mon objectif était purement personnel : comprendre les lois qui régissent le mouvement d’une fusée et les modéliser sous forme d’un simulateur interactif. Je voyais cela comme une façon d’approfondir mes connaissances en physique et en programmation, en dehors du cadre scolaire. À aucun moment, je n’avais envisagé que ce projet pourrait avoir une utilité pour d’autres.

Mais en avançant, quelque chose a changé. Lorsque j’ai commencé à montrer mon simulateur à des amis ou à des camarades de classe, j’ai vu qu’ils y trouvaient un intérêt que je n’avais pas anticipé. Certains y voyaient un outil pédagogique, d’autres une manière concrète de visualiser des phénomènes qu’ils avaient du mal à comprendre uniquement à l’aide d’équations. C’est à ce moment-là que j’ai réalisé que ce projet, que j’avais d’abord pensé comme une expérience individuelle, pouvait en réalité servir à une petite communauté.

Cette prise de conscience m’a amené à modifier certains aspects du projet. J’ai commencé à soigner l’interface pour la rendre plus claire, à simplifier les termes affichés pour qu’ils soient compréhensibles sans connaissances avancées, à ajouter des messages d’erreur explicites. J’ai aussi amélioré la documentation du code, pour qu’un élève ou un enseignant puisse s’y plonger sans être bloqué par des détails techniques.

Je me suis rendu compte que ce projet pouvait combler un manque entre la théorie et la pratique. En classe, on parle d’accélération, de résistance de l’air, de gravité, mais ces concepts restent parfois abstraits. Le simulateur permet de les manipuler, de les tester, de voir immédiatement ce qui change lorsqu’on modifie la masse ou la poussée. Ce lien direct entre formule et comportement rend la science plus accessible.

J’ai également commencé à réfléchir à des usages collectifs : est-ce qu’un club scientifique pourrait l’utiliser ? Est-ce qu’un enseignant pourrait proposer des mini-projets à ses élèves en partant de mon simulateur ? Est-ce qu’on pourrait l’adapter pour des présentations dans des événements scolaires ou associatifs ? Ces idées ne sont pas encore toutes concrétisées, mais elles montrent que le projet a ouvert une nouvelle perspective.

Enfin, cette dimension sociale m’a permis de repenser le sens du projet dans le cadre du CAS. Je ne faisais plus seulement preuve de créativité et d’engagement personnel, je proposais aussi un service à la communauté éducative, aussi modeste soit-il. C’est cette évolution que je retiens le plus : celle d’un projet tourné vers moi, devenu peu à peu tourné vers les autres.

Synthèse

Au départ purement individuel, mon projet a évolué vers une forme de service aux autres. J’ai pris conscience qu’un travail technique, s’il est bien conçu, peut devenir un outil utile, un support pédagogique, ou même une source d’inspiration. C’est cette dimension sociale inattendue qui a donné un nouveau sens à mon engagement dans le cadre du CAS.

CAS FUSÉE – 13 – Vers l’extérieur – Mise à disposition du projet à la communauté

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:57:53 +0000

Partie 4 - Vers l’extérieur - Mise à disposition du projet à la communauté

Après plusieurs mois de développement, mon projet avait atteint un stade suffisamment avancé pour être utilisé non seulement par moi, mais aussi par d’autres. À ce moment-là, l’idée a commencé à émerger : pourquoi ne pas le partager ? Après tout, le simulateur de trajectoire que j’avais construit pouvait servir à d’autres élèves, enseignants ou passionnés de physique.

La première étape a été de mettre le projet en ligne, sur un serveur accessible via un nom de domaine. J’ai utilisé un hébergement que je gérais moi-même, avec un nom de domaine personnel, ce qui m’a permis de configurer un environnement Docker avec une base de données, un reverse proxy, le backend Symfony et le frontend. Le site est devenu accessible à l’adresse : padr.fr/rocket

Une fois le site accessible publiquement, j’ai commencé à en parler autour de moi. J’ai présenté le projet à deux enseignants, qui y ont vu un outil pédagogique intéressant pour illustrer les notions de poussée, de vitesse, de gravité, et pour montrer ce que signifie concrètement résoudre une équation différentielle. Le simulateur est interactif, les données sont personnalisables, et le code source est lisible. Cela en fait une ressource utile en classe ou en atelier scientifique, surtout pour les lycéens.

En parallèle, j’ai publié le code sur une plateforme de gestion de version (GitHub), avec une documentation minimale pour expliquer le fonctionnement du projet, la structure des entités, les routes d’API, et quelques instructions d’installation. Le but n’était pas d’en faire une plateforme publique très fréquentée, mais simplement de rendre le projet transparent et accessible à d’autres développeurs ou curieux. Cela m’a aussi permis de formaliser mon travail en expliquant mes choix techniques et en structurant mieux mon dépôt.

J’ai reçu quelques retours positifs, parfois techniques, parfois pédagogiques. Certains m’ont proposé des améliorations, d’autres m’ont félicité pour la clarté de l’interface. Ces échanges m’ont montré que le projet avait dépassé le cadre personnel pour devenir quelque chose de potentiellement utile à une petite communauté.

Cette ouverture m’a aussi fait prendre conscience d’une chose : lorsque l’on met son travail à disposition, on se met à la place de l’utilisateur. On pense à la documentation, à l’ergonomie, à la robustesse. Ce n’est plus un simple « projet d’élève », c’est un outil que d’autres vont utiliser, critiquer, voire améliorer. Cela change profondément la façon de concevoir et de maintenir un projet.

Ce projet est maintenant disponible sur GitHub

Une ouverture Open Source vers le monde !

Synthèse

Partager mon projet m’a permis de franchir une nouvelle étape : celle du service. J’ai compris que ce que je construisais pouvait avoir une utilité concrète pour d’autres, en particulier dans le domaine de l’éducation. Cela m’a donné envie de continuer à améliorer le projet, non seulement pour moi, mais pour les autres. C’est aussi ce qui a amorcé la réflexion développée dans l’article suivant.

CAS FUSÉE – 12 – Passage à un projet logiciel complet – Création d’une interface web interactive et complète

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:54:26 +0000

Partie 3 - Passage à un projet logiciel complet - Création d’une interface web interactive et complète

Une fois mon API opérationnelle avec Symfony et API Platform, j’ai pu me concentrer sur la construction de l’interface utilisateur, en JavaScript, pour permettre une interaction fluide avec l’API. L’objectif était de proposer une expérience complète : connexion, consultation des modèles de fusées, lancement de simulations, et enregistrement des résultats.

Le point de départ a été la page de connexion. Plutôt que d’utiliser un formulaire Symfony classique avec form_login, j’ai opté pour un fonctionnement 100% JavaScript, en envoyant les identifiants à la route /api/login via fetch(). En réponse, le serveur retourne un JWT (JSON Web Token) que je stocke côté client et que je réutilise pour authentifier les requêtes suivantes. Ce choix rend l’application stateless, donc plus simple à maintenir et plus flexible à déployer.

Pour centraliser toute cette logique, j’ai créé une classe JavaScript nommée RocketAuthentication, contenant des méthodes statiques comme :

login(username, password),
logout(),
isAuthenticated(),
fetchWithAuth(url, options).

Cette classe gère le stockage du token, l’ajout automatique du header Authorization, et la redirection vers la page de login en cas d’échec. Cela m’a permis de sécuriser toutes les requêtes sans dupliquer le code partout.

Ensuite, j’ai construit différentes pages ou composants :

un tableau listant les RocketModules appartenant à l’utilisateur connecté,
des formulaires pour en ajouter ou modifier,
une interface pour composer une simulation en combinant un module, des sous-modules et un script de mouvement,
une visualisation en temps réel du vol à l’aide de Canvas,
et une possibilité d’enregistrer les résultats de la simulation pour les consulter plus tard.

Tout cela repose sur des appels fetch() à l’API, enrichis avec le token d’authentification, et des réponses JSON que je transforme dynamiquement en éléments HTML. L’interface utilise Tailwind CSS, ce qui m’a permis de gagner du temps sur le style tout en gardant un rendu propre et lisible.

J’ai aussi mis en place une gestion des erreurs utilisateur : messages si un champ est mal rempli, si l’identifiant est déjà pris, ou si une requête échoue. Cela donne à l’application un aspect plus professionnel, et évite les frustrations pour les utilisateurs.

Enfin, j’ai intégré un système de déconnexion simple, qui efface le token du stockage local et redirige vers la page de login. Ce genre de détail peut sembler mineur, mais il est essentiel pour offrir une application complète et cohérente.

Synthèse

La création de l’interface web m’a permis de relier toutes les briques de mon projet : physique, calcul, API, et interaction utilisateur. J’ai appris à créer une expérience fluide, où chaque action côté client déclenche une opération serveur via une API sécurisée. Cette étape m’a aussi sensibilisé à l’importance de l’ergonomie, de la robustesse, et de la clarté dans une interface destinée à être utilisée par d’autres que moi.

CAS FUSÉE – 11 – Passage à un projet logiciel complet – Développement de la partie serveur avec API Platform

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:47:07 +0000

Partie 3 - Passage à un projet logiciel complet - Développement de la partie serveur avec API Platform

Une fois que j’avais appris à utiliser Symfony et mis en place les premières entités, j’ai intégré API Platform, un outil extrêmement puissant qui permet de transformer une application Symfony en API REST complète, sans avoir à coder manuellement chaque route, contrôleur ou format de réponse.

Ce qui m’a d’abord impressionné, c’est la simplicité d’utilisation : en ajoutant quelques annotations ou attributs PHP à mes classes d’entités, API Platform expose automatiquement des routes comme GET /api/rocket_modules, POST /api/rocket_modules, etc. Cela m’a permis de gagner un temps considérable, tout en respectant les standards de l’architecture REST.

Par exemple, en exposant mes entités comme RocketModule, RocketSubModule ou RocketMotionScript, j’ai immédiatement obtenu des routes pour les consulter, les créer, les modifier ou les supprimer. De plus, API Platform génère automatiquement une documentation interactive (avec Swagger UI) que j’ai pu utiliser pour tester les requêtes et vérifier le bon fonctionnement de l’API.

J’ai également découvert que l’on pouvait configurer très finement les opérations disponibles sur chaque entité : on peut, par exemple, autoriser seulement les lectures (GET), ou bien restreindre l’écriture (POST, PUT, DELETE) aux utilisateurs authentifiés. Ces règles peuvent être définies avec des expressions Symfony (comme is_granted(‘ROLE_USER’)), ce qui permet de gérer très précisément les droits d’accès.

Un autre aspect très utile d’API Platform est sa gestion de la sérialisation : il est possible de choisir quels champs sont exposés dans les réponses ou acceptés dans les requêtes grâce aux groupes de normalisation/dénormalisation. Cela m’a permis de cacher certaines informations sensibles (comme l’utilisateur associé à une entité) ou de structurer les réponses pour qu’elles soient plus claires côté client.

J’ai aussi pu tirer parti des filtres automatiques proposés par API Platform : en configurant quelques annotations, il devient possible de filtrer les résultats avec des paramètres dans l’URL (par exemple : GET /api/rocket_modules?owner.id=1). Cela simplifie énormément le travail côté frontend, car je n’ai pas besoin d’écrire des routes personnalisées pour chaque cas.

L’API ainsi construite a été le cœur du lien entre le backend Symfony et le frontend JavaScript. Grâce à elle, mon application web peut envoyer des requêtes HTTP, créer de nouveaux modèles de fusées, lancer des simulations, enregistrer des scripts de mouvement, et récupérer des résultats — tout cela de façon sécurisée, avec des permissions bien définies.

En parallèle, j’ai aussi pris soin de tester mes routes manuellement via Swagger, puis en JavaScript avec fetch() et mon gestionnaire d’authentification personnalisé (RocketAuthentication). Chaque test m’a permis de peaufiner les réponses, d’ajouter des validations, ou de corriger des oublis de configuration dans les entités.

Je me suis aidé de l’outil Postman pour débugger mes appels à l’Api. Postman permet de créer des requêtes HTTP vers le serveur et de voir tout ce qu’il se passe simplement :

Synthèse

API Platform a profondément simplifié le développement de l’API de mon projet, tout en m’obligeant à structurer proprement mes entités et à penser à la sécurité dès le départ. J’ai appris à créer une API REST moderne, documentée, filtrable, et sécurisée. C’est cette couche qui permet désormais à mon interface web de communiquer efficacement avec la base de données, de manière fluide et évolutive.

CAS FUSÉE – 10 – Passage à un projet logiciel complet – Découverte de PHP et du framework Symfony

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:44:10 +0000

Partie 3 - Passage à un projet logiciel complet - Découverte de PHP et du framework Symfony

Pour développer la partie serveur de mon projet, j’ai dû apprendre un langage que je n’avais jamais utilisé auparavant : PHP. Ce n’était pas un choix imposé, mais plutôt une décision guidée par la réputation du framework Symfony, largement utilisé dans les projets web professionnels, et très bien documenté.

Heureusement, le passage de JavaScript à PHP ne m’a pas semblé aussi difficile que je l’aurais cru. Une fois qu’on a compris les concepts fondamentaux de la programmation — variables, fonctions, boucles, objets, classes — il devient beaucoup plus facile d’aborder un nouveau langage. Certes, la syntaxe change, et certains détails peuvent surprendre (comme la gestion des tableaux ou des chaînes), mais la logique globale reste très proche.

Par exemple, la création de classes en PHP est presque identique à ce que j’avais vu en JavaScript : définition d’un constructeur, méthodes, propriétés, visibilité (public, private), etc. Les idées de modularité, d’encapsulation, ou d’héritage sont similaires. Le changement principal concerne la rigueur : PHP (surtout en version 8+) est plus strict que JavaScript, et cela m’a poussé à mieux organiser mon code.

En revanche, ce qui a vraiment représenté un saut en complexité, ce n’est pas tant le langage PHP lui-même que l’utilisation du framework Symfony. Symfony impose une architecture précise, avec ses conventions, ses dépendances, ses annotations, et ses outils en ligne de commande. C’est un écosystème très riche, mais cela peut être intimidant au début. Il m’a fallu un peu de temps pour comprendre comment tout s’emboîte : entités, contrôleurs, routes, services, événements, etc.

L’un des premiers aspects que j’ai appréciés, c’est la gestion automatique des entités avec Doctrine (l’ORM de Symfony). Il suffit de définir une classe PHP représentant une entité (comme une fusée ou une trajectoire), et Symfony génère les tables SQL correspondantes, ainsi que toutes les opérations de base (création, mise à jour, suppression). Cela m’a fait gagner beaucoup de temps, tout en m’obligeant à penser les relations entre objets (OneToMany, ManyToMany, etc.).

Un autre point très puissant de Symfony est son intégration avec API Platform. Grâce à ce bundle, je n’ai quasiment pas eu besoin de coder les routes de mon API manuellement. Il suffit d’annoter une entité avec des métadonnées, et API Platform expose automatiquement les endpoints nécessaires pour interagir avec cette entité en JSON. J’ai pu ainsi construire en quelques heures une API REST complète, avec gestion automatique du filtrage, de la pagination, et de la sérialisation.

Symfony m’a aussi permis de mettre en place un système d’authentification par JWT, en combinant quelques bundles comme lexik/jwt-authentication-bundle. Après avoir bien compris comment fonctionne le système de firewall et de “security voter”, j’ai pu protéger les routes, restreindre certaines opérations aux utilisateurs connectés, et exposer un endpoint /api/login utilisé directement par mon frontend.

Enfin, j’ai appris à configurer Symfony pour fonctionner en local avec Docker, ce qui simplifie énormément le déploiement. J’ai même couplé le tout avec une base de données MySQL et un reverse proxy, ce qui m’a permis de simuler un environnement de production complet.

Comparatif JavaScript / PHP (Symfony)

Aspect	JavaScript	PHP (avec Symfony)
Déclaration de classes	`class MaClasse { ... }`	`class MaClasse { ... }` (similaire)
Constructeurs	`constructor(...)`	`__construct(...)`
Visibilité des membres	`this.nom = ...` (public par défaut)	`public`, `private`, `protected` explicites
Typage	Faiblement typé	De plus en plus fortement typé (avec PHP 8)
Organisation du projet	Libre, souple	Structurée (MVC, dossiers imposés)
Routage/API	Manuel (`fetch`, Express, etc.)	Automatisé via API Platform
Sécurité	À construire manuellement	Intégrée avec bundles et firewalls

Synthèse

Apprendre PHP ne m’a pas semblé très difficile, car les bases étaient similaires à celles que j’avais acquises en JavaScript. Ce qui a demandé le plus de travail, c’est la prise en main du framework Symfony, qui impose une manière rigoureuse de structurer un projet. Cela m’a forcé à adopter une organisation professionnelle, à mieux séparer les responsabilités dans mon code, et à construire une API propre, documentée et sécurisée. C’est cette étape qui a fait passer mon projet d’un simple prototype à une application sérieuse.

CAS FUSÉE – 9 – Passage à un projet logiciel complet – Passage à une architecture plus complexe

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:39:23 +0000

Partie 3 - Passage à un projet logiciel complet - Passage à une architecture plus complexe

Après avoir terminé une version stable de ma simulation en JavaScript, j’ai commencé à réfléchir à ce que le projet pourrait devenir s’il devait accueillir plusieurs utilisateurs, gérer des modèles de fusées différents, ou sauvegarder des données. C’est à ce moment-là que j’ai compris que je ne pouvais plus me contenter de tout gérer dans le navigateur. Il me fallait une partie serveur, une base de données, et une organisation plus structurée du code. Mon petit projet personnel commençait à devenir une véritable application web.

D’autant plus que j’ai été contacté par mail par un étudiant italien qui avait eu connaissance de mon projet à travers un forum :

Après avoir échangé avec cet étudiant, il était maintenant clair que je devais répondre à plusieurs besoins.

Le premier besoin évident était la persistance des données. Jusqu’ici, chaque simulation était effacée dès que la page était rechargée. Je voulais permettre à un utilisateur de créer plusieurs modèles de fusées, de modifier leurs paramètres, et de consulter l’historique de ses simulations. Cela impliquait la mise en place d’un système de stockage, et donc d’une base de données.

J’ai aussi voulu ajouter un système d’authentification, afin que chacun puisse retrouver ses propres données. Cela m’a amené à découvrir les principes de la sécurité web : création de comptes, identifiants, mots de passe, gestion de sessions ou de jetons. J’ai fait le choix d’un fonctionnement stateless, basé sur des JWT (JSON Web Tokens), pour éviter d’avoir à gérer des sessions côté serveur. Cela s’intégrait mieux dans une architecture API moderne.

Pour structurer cette nouvelle partie du projet, j’ai choisi de travailler avec Symfony, un framework PHP que je ne connaissais pas encore mais qui m’a paru très complet. Il offre une gestion puissante des entités, une bonne organisation du code, et une compatibilité directe avec les bases de données relationnelles. Symfony m’a aussi permis de construire facilement une API REST, grâce au bundle API Platform, que j’ai intégré dès les premières étapes.

Cette transformation du projet m’a obligé à penser autrement. Là où je manipulais auparavant des objets JavaScript dans une seule page HTML, je devais maintenant :

définir des entités persistées en base (RocketModule, RocketSubModule, RocketMotionScript),
créer des relations entre elles (ManyToMany),
exposer ces données sous forme de ressources accessibles via l’API,
sécuriser l’accès avec des firewalls, et restreindre certaines opérations aux utilisateurs authentifiés.

Il m’a aussi fallu synchroniser le frontend JavaScript avec cette nouvelle API Symfony. Cela m’a conduit à revoir toute ma logique côté client : au lieu de stocker les données localement, je devais faire des appels fetch() pour interroger l’API, ajouter les bons headers d’authentification, gérer les erreurs réseau, etc. J’ai même créé une classe dédiée (RocketAuthentication) pour encapsuler cette logique.

Ce passage à un projet complexe a été un vrai tournant. J’ai compris que pour que mon projet soit utilisable à plus grande échelle, il fallait qu’il repose sur une base technique solide, avec des couches clairement séparées : données, logique, interface. Cette évolution m’a demandé beaucoup de temps, mais elle a profondément enrichi ma compréhension du développement logiciel.

Synthèse

Le passage d’un simple simulateur local à une application web complète a transformé la nature du projet. J’ai découvert la notion d’architecture logicielle, appris à utiliser un framework professionnel, et mis en place une API sécurisée. Cette étape a marqué l’entrée de mon projet dans une nouvelle dimension : celle de la scalabilité, de l’organisation, et de l’ouverture à d’autres utilisateurs.

CAS FUSÉE – 8 – Du prototype à l’étude mathématique – Rédaction de l’Internal Assessment (IA)

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:30:48 +0000

Partie 2 - Du prototype à l’étude mathématique - Rédaction de l’Internal Assessment (IA)

Alors que je poursuivais le développement de ma simulation JavaScript, j’ai rapidement réalisé que le projet pouvait aussi servir de base solide pour mon Internal Assessment (IA) en mathématiques dans le cadre de l’IB. J’avais déjà collecté un grand nombre de données, formulé des équations différentielles, et exploré différentes méthodes numériques. Le tout constituait une problématique concrète, bien ancrée dans un cadre scientifique rigoureux.

Pour l’IA, j’ai choisi de recentrer mon travail sur la modélisation mathématique du mouvement d’une fusée, en mettant l’accent sur l’analyse des différentes méthodes de résolution numérique. J’ai délaissé temporairement JavaScript au profit de Matlab, un environnement que je connaissais déjà un peu et qui est parfaitement adapté à ce type de travail mathématique. Matlab m’a permis de faire des calculs précis, de tracer des graphes clairs, et de tester rapidement les effets de différents paramètres (pas de temps, masse initiale, poussée, etc.).

J’ai structuré mon IA autour de trois méthodes principales : la méthode d’Euler, la méthode de Heun, et Runge-Kutta 4. Pour chacune, j’ai :

expliqué le principe mathématique,
montré la mise en œuvre algorithmique,
appliqué la méthode à une fusée fictive,
comparé les résultats obtenus (trajectoires, erreurs cumulées, stabilité numérique).

Ce travail m’a permis de mettre en évidence les avantages et les limites de chaque méthode. J’ai pu démontrer que, même si Euler est facile à coder, il peut générer de grandes erreurs si les variations sont rapides, tandis que RK4 offre une bien meilleure précision, au prix d’un peu plus de calculs. J’ai aussi exploré des critères de comparaison comme la convergence ou le comportement asymptotique des trajectoires.

Au-delà des résultats numériques, ce travail m’a permis de formaliser rigoureusement ce que j’avais expérimenté dans ma simulation JavaScript. En quelque sorte, l’IA a été l’occasion de théoriser ce que j’avais d’abord exploré de manière intuitive. Cela m’a aussi forcé à clarifier mes raisonnements, à poser des hypothèses, et à justifier chaque étape de manière logique, comme l’exige le cadre IB.

Le lien avec ma simulation ne s’est pas rompu pour autant. Je me suis même servi de certaines visualisations Matlab pour améliorer mon affichage graphique côté JavaScript. Et une fois l’IA terminée, j’ai pu enrichir ma simulation grâce à ce que j’avais appris : j’ai notamment validé que les calculs que j’effectuais côté client étaient cohérents avec les résultats de Matlab.

Synthèse

Rédiger mon Internal Assessment m’a permis de prendre du recul sur mon projet. J’ai pu analyser les fondements mathématiques de ma simulation, comparer plusieurs approches numériques, et apprendre à argumenter de manière rigoureuse. C’est aussi la première fois que je voyais un projet personnel trouver une vraie place dans un cadre académique.

Annexe

Le document complet de l’Internal Assessment, rédigé dans le cadre du programme IB, est joint en annexe du rapport CAS. Il contient l’analyse détaillée des méthodes numériques appliquées à la trajectoire d’une fusée, ainsi que les graphiques, raisonnements mathématiques, et conclusions issues du travail mené sous Matlab.

Vous pouvez le télécharger en cliquant sur l’icône.

CAS FUSÉE – 7 – Du prototype à l’étude mathématique – Réalisation de la première version JavaScript

pierre.ange.delbary.rouille@gmail.com — Tue, 22 Apr 2025 15:25:58 +0000

Partie 2 - Du prototype à l’étude mathématique - Réalisation de la première "vraie" version JavaScript

Une fois le premier modèle mathématique en place, j’ai décidé de passer à une version plus propre, complète et structurée en JavaScript. L’idée était de passer d’un simple script à une vraie application web interactive, qui permette de visualiser en temps réel le vol d’une fusée à partir de paramètres choisis par l’utilisateur.

J’ai commencé par revoir l’architecture de mon code. J’ai transformé ma boucle de simulation en fonction réutilisable, prenant en entrée un objet contenant les paramètres physiques de la fusée (masse, poussée, surface frontale, etc.). J’ai ensuite déplacé le calcul de la trajectoire dans une classe à part, pour isoler les éléments liés au mouvement. Cela m’a permis de préparer le terrain pour une gestion multiple de modèles de fusées dans le futur.

Sur le plan visuel, j’ai utilisé le canvas HTML5 pour tracer l’évolution de la position de la fusée en fonction du temps. J’ai aussi affiché les courbes de la vitesse et de l’accélération à l’aide de graphiques simples, pour que l’utilisateur puisse visualiser l’évolution du vol étape par étape. Même si le rendu était basique, cette étape m’a montré à quel point une simulation peut devenir pédagogique si elle est bien présentée.

L’interface HTML était encore rudimentaire : quelques champs pour entrer les paramètres (masse, poussée, durée), un bouton “Lancer”, et un petit encart pour afficher les résultats chiffrés. Mais cela suffisait à créer une interaction utilisateur. Chaque clic lançait un calcul complet et actualisait les graphiques. J’avais l’impression que mon programme « vivait ».

Pour que le code reste compréhensible et évolutif, j’ai commencé à créer un dossier js/Simulation, avec des modules séparés : un pour les constantes physiques, un autre pour les équations de mouvement, un pour l’historique des trajectoires, etc. Ce travail de séparation des responsabilités était nouveau pour moi, mais il m’a beaucoup aidé par la suite, notamment lors de l’intégration avec le backend.

J’ai aussi pris le temps d’ajouter une gestion des erreurs : si l’utilisateur entrait une poussée négative ou une masse trop faible, la simulation affichait un message explicatif plutôt que de planter. C’était un détail important pour rendre le programme utilisable par quelqu’un d’autre que moi.

Ce prototype a été la première version publique de ma simulation. Je l’ai hébergée temporairement pour la montrer à quelques amis et à un professeur de physique, ce qui m’a permis de recueillir des retours. Certains trouvaient que l’affichage était trop rapide, d’autres auraient voulu pouvoir zoomer sur les courbes. Ces remarques m’ont poussé à imaginer des évolutions futures : ajout de plusieurs axes (X/Y), inclinaison au lancement, ou même un suivi 3D.

Voilà ce que cela donnait, je commençais à être fier :

Synthèse

La réalisation de cette première version m’a permis de passer d’une idée scientifique abstraite à une application interactive concrète. J’ai appris à structurer un projet JavaScript plus complexe, à créer une interface utilisateur simple mais fonctionnelle, et à transformer un ensemble de calculs en une simulation visuelle. C’est à ce moment-là que j’ai commencé à considérer le projet comme une vraie application, pas seulement comme un exercice personnel.