Application souveraine - AUXASUITE WEB

Ce projet a été réalisé dans le cadre de mon alternance au sein de AUXASPHERE SAS, où j’occupais le poste de développeur full stack.

L’entreprise travaillait sur le développement d’une application dite “souveraine”, c’est-à-dire une solution indépendante des grands acteurs du numériques, visant à garantir un meilleur contrôle des données pour ses utilisateurs.

L’objectif de ce projet était de concevoir une plateforme SaaS complète permettant aux entreprises de gérer leurs données et leurs outils de communication au sein d’un environnement unique. Le Software as a Service, également connu sous le nom de SaaS, est un service basé sur le cloud où, au lieu de télécharger un logiciel que votre PC de bureau ou votre réseau professionnel peut exécuter et mettre à jour, vous accédez à une application via un navigateur internet. Cette application avait vocation à proposer une alternative à des solutions largement utilisées telles que Microsoft Outlook ou Microsoft Teams.

Pour se faire, je suis intervenu sur plusieurs tâches permettant de développer les services de l’application.

L’objectif principal de ce projet était de concevoir une application SaaS complète, capable de regrouper plusieurs outils essentiels au fonctionnement d’une entreprise au sein d’une seule et même plateforme.

Il s’agissait notamment de proposer des fonctionnalités telles que la gestion de fichiers, la communication interne, l'organisation d'événements ou encore la gestion des utilisateurs.

Au-delà de l’aspect fonctionnel, le projet visait également à proposer une alternative crédible à des solutions existantes comme Microsoft Outlook ou Microsoft Teams, en mettant l’accent sur la souveraineté des données et la maîtrise de l’environnement technique.

Un autre objectif était de développer une application moderne, évolutive et sécurisée, reposant sur une architecture en microservices. Chaque fonctionnalité devait être indépendante afin de faciliter la maintenance, les mises à jour et l’ajout de nouvelles briques applicatives.

En tant qu’apprenti développeur full stack, mon objectif était de contribuer au développement de plusieurs fonctionnalités du produit, aussi bien côté front-end avec React & TypeScript que côté back-end avec Java Spring WebFlux et Node.js. Il s’agissait également de m’intégrer dans un environnement de développement professionnel, en participant aux choix techniques, aux échanges d'équipe et à l’amélioration continue du produit.

.Enjeux

L’un des principaux enjeux de ce projet résidait dans la conception d’une application capable de proposer plusieurs fonctionnalités essentielles au sein d’un seul environnement. Il fallait réussir à garantir une cohérence globale entre les services tels que le stockage de fichiers, la messagerie, le calendrier, les appels vidéo ou encore la gestion de l'organisation de l'entreprise.

Un autre enjeu important concernait la souveraineté des données. Il fallait proposer une solution permettant aux entreprises de garder le contrôle sur leurs informations, ce qui impliquait de concevoir une architecture fiable, sécurisée et maîtrisée de bout en bout.

Le choix d’une architecture en microservices représentait également un enjeu majeur. Chaque service devait être autonome tout en étant capable de communiquer efficacement avec les autres. Cette organisation visait à améliorer la scalabilité du système et à faciliter les évolutions futures, mais elle nécessitait une rigueur importante dans la conception.

Enfin, le projet impliquait une forte exigence en termes d’expérience utilisateur. Malgré la complexité des fonctionnalités proposées, l’application devait rester intuitive et agréable à utiliser, afin de favoriser son adoption par les utilisateurs finaux.

Le projet comportait plusieurs risques en raison de la complexité du système dans son ensemble. Lorsqu'on crée une application qui regroupe de nombreuses fonctionnalités, les risques d'incohérences entre les différents modules augmentent. Cela peut se manifester de différentes manières, notamment en ce qui concerne l'interface utilisateur ou le comportement de l'application. Par exemple, les différents modules peuvent ne pas être parfaitement compatibles, ce qui peut entraîner des erreurs ou des problèmes de fonctionnement. Le projet présentait donc des risques liés à la complexité globale du système.

L'architecture en microservices présente également des défis techniques. Si les services ne communiquent pas correctement entre eux, cela peut entraîner des erreurs. C'est particulièrement vrai si les échanges et les dépendances entre les services ne sont pas bien gérés. L'architecture en microservices nécessite donc une gestion soigneuse de la communication et synchronisation entre les services pour éviter les erreurs. Les échanges entre les services doivent être bien planifiés et les dépendances entre les services doivent être clairement définies pour que l'architecture en microservices fonctionne correctement.

Un autre risque concernait la performance de l’application. La multiplication des services et des appels entre eux pouvait entraîner des latences si l’architecture n’était pas correctement optimisée.

Par ailleurs, la gestion des données représentait un enjeu sensible. L’utilisation de plusieurs bases de données adaptées à des besoins différents nécessitait une bonne compréhension des modèle de données afin d’éviter des incohérences ou des problèmes d’intégrité.

Ce projet a été réalisé au sein de l’équipe de développement d’Auxasphere SAS, composée de cinq personnes. En tant que développeur full stack en alternance, j’étais pleinement intégré à l’équipe et participais activement au développement des différentes fonctionnalités de l’application.

Le travail était organisé selon une méthodologie Agile, permettant d’assurer une progression continue du projet et une bonne réactivité face aux évolutions des besoins. Le quotidien de l’équipe était rythmé par des réunions appelées “Daily meetings”, durant lesquelles chaque membre présentait l’avancement de ses tâches, les difficultés rencontrées ainsi que les actions à venir. Ces échanges favorisaient la communication et permettaient de résoudre rapidement les éventuels points bloquants.

En complément, toutes les deux semaines, une réunion interne appelée “Dev Time” était organisée. Lors de ces sessions, chaque membre de l’équipe pouvait présenter un sujet technique, une veille technologique ou une problématique rencontrée dans le cadre du projet. Ces moments d’échange contribuaient à enrichir les connaissances de l’équipe et à introduire de nouvelles idées susceptibles d’améliorer le produit.

La collaboration ne se limitait pas uniquement à l’équipe de développement. Nous étions également amenés à échanger avec des équipes en charge des aspects juridiques et de conformité, notamment sur des sujets liés à la protection des données. Dans ce cadre, j’ai pu participer à des sessions de formation portant sur des réglementations telles que le RGPD ainsi que les directives NIS Directive et NIS2 Directive. Ces interventions m’ont permis de mieux comprendre les enjeux liés à la sécurité et à la gestion des données dans un contexte professionnel.

La communication au sein de l’équipe reposait également sur des échanges réguliers et informels. Cela facilitait la coordination autour des choix techniques et des problèmes rencontrés. Grâce à cette organisation, j'ai pu améliorer mes compétences en travail d'équipe, en communication professionnelle et en partage de connaissances.

Pour finir, nous avons utilisé l'outil de ticketing Monday.com pour suivre les tâches. Cela nous a permis de structurer notre travail et de voir où nous en étions dans le projet. Nous avons également utilisé GitLab pour gérer les différentes versions de notre code. Cela nous a beaucoup aidés à travailler ensemble et à garder toutes les versions du code en ordre.

.Configuration et prise en main de l'environnement

La première étape a consisté à me familiariser avec l’application existante. Pour cela, j’ai utilisé la version en production afin de découvrir les différentes fonctionnalités proposées. Cette phase de prise en main m’a permis d’observer l’organisation générale de la plateforme, la disposition des interfaces ainsi que les parcours utilisateurs. L’objectif était de comprendre concrètement le fonctionnement du produit afin de pouvoir développer des fonctionnalités adéquates plus tard.

Par la suite, j'ai installé et configuré mon environnement de travail. J'ai utilisé un mini-ordinateur de type Intel NUC pour le développement, il est conçu pour offrir de bonnes performances dans un format compact. Mon poste de travail fonctionnait sous le système d'exploitation GNU/linux Ubuntu. J'ai donc dû installer et configurer Ubuntu afin de préparer l’environnement de développement.

Une fois le système opérationnel, j’ai mis en place les outils nécessaires au projet, notamment Docker. L’application reposant sur une architecture en microservices, Docker permettait de lancer et de gérer les différents services de manière isolée, chacun étant exécuté dans son propre conteneur.

Dans ce contexte, j’ai également été amené à configurer certains services utilisés par l’application, comme RabbitMQ, qui permet la communication entre les différents microservices via un système de messages. La création de comptes et la configuration de ces outils faisaient partie intégrante de cette phase de préparation.

.Développement front-end

Au début de mon alternance, mon maître d’apprentissage a fait le choix de me faire évoluer progressivement sur le projet. J’ai ainsi commencé par des tâches orientées front-end, avant d’aborder par la suite des sujets back-end et full stack.

Cette montée en compétence, fait de manière progressive m'a permis de mieux comprendre l'architecture de l'application. J'ai pu ainsi intervenir sur des parties plus complexes en ayant une bonne connaissance de l'ensemble.

Mes premières interventions ont porté sur des corrections et des améliorations de l’interface utilisateur. Par exemple, j’ai été amené à corriger un problème d’inversion de couleurs dans le service de messagerie instantanée, qui survenait lors du survol d’un élément avec la souris. Ce type de correction, bien qu'il soit ciblé, nécessite de comprendre parfaitement la structure des composants React et la gestion des styles. Cela permet de garantir que son comportement est cohérent avec le reste de l'interface.

J’ai également travaillé sur des fonctionnalités liées à l’affichage des données, notamment dans les services “Organisation” et “Drive”, qui intégraient un système de pagination. L’objectif était de modifier le nombre d’éléments affichés par défaut afin d’améliorer l’expérience utilisateur.

Une des tâches les plus techniques que j’ai réalisées concernait l’intégration d’un système d'émojis dans le service de chat. Cette fonctionnalité consistait à ajouter une icône au niveau du champ de saisie, permettant d’ouvrir une fenêtre contenant une sélection d’émojis. L’utilisateur pouvait ainsi insérer des émojis directement dans son message.

Lors de cette implémentation, j'ai rencontré une difficulté avec la gestion du curseur dans le champ de texte. Lorsque plusieurs émojis étaient insérés, le curseur revenait automatiquement au début du contenu, ce qui gênait l'expérience utilisateur. Pour résoudre ce problème, j'ai dû gérer manuellement la position du curseur. J'ai calculé son emplacement avant la mise à jour du contenu, puis je l'ai repositionné correctement après chaque insertion. Cette solution m'a donné un comportement fluide et naturel lors de la saisie.

.Développements back-end et full stack

Au fur et à mesure de mon apprentissage, j’ai été amené à intervenir sur des tâches plus complexes, impliquant à la fois le front-end et le back-end. Cette évolution m’a permis de mieux comprendre les interactions entre les différents services de l’application ainsi que les mécanismes de communication au sein d’une architecture en microservices.

Une première fonctionnalité sur laquelle j’ai travaillé concernait la gestion du partage d'écran dans le service de visioconférence. L’objectif était d’améliorer le comportement de l’interface lors des appels vidéo. Lorsqu’un utilisateur partageait son écran, celui-ci devait automatiquement passer au premier plan pour tous les participants. Si un second utilisateur lançait à son tour un partage d’écran, il devait prendre la priorité et s’afficher en premier plan chez tous les utilisateurs. Lorsque ce second partage était arrêté, l’affichage devait revenir automatiquement au premier utilisateur ayant initié un partage. Enfin, lorsque plus aucun partage n’était actif, l’interface devait revenir à une vue en mosaïque ( plus personne en premier plan ).

Cette fonctionnalité reposait sur l’utilisation de MediaPipe, une bibliothèque développée par Google permettant de traiter des flux multimédias en temps réel, notamment dans le cadre de la vision par ordinateur. Elle était utilisée dans le projet pour gérer certains aspects des appels vidéo.

Toujours dans ce contexte, j’ai travaillé sur l’amélioration du système de segmentation vidéo. Initialement, seule une fonctionnalité de floutage de l'arrière plan lors d'un appel vidéo était disponible. J’ai été chargé d’ajouter la possibilité pour l’utilisateur de remplacer cet arrière-plan par une couleur unie ou une image personnalisée. La segmentation consiste à distinguer, dans une image ou une vidéo, les pixels appartenant à un élément spécifique, comme le corps d’une personne. En exploitant des fonctions fournies par la bibliothèque, notamment celles permettant de manipuler les données de pixels, j’ai pu isoler la silhouette de l’utilisateur et appliquer dynamiquement le fond choisi. Cette tâche a nécessité plusieurs phases de tests afin d’obtenir un rendu visuel cohérent et performant.

Une autre problématique importante concernait la gestion des utilisateurs au sein de l’application. Lorsqu'un utilisateur était supprimé de l'organisation, par exemple s'il quittait l'entreprise, il restait tout de même dans la base de données. Cela signifiait qu'il pouvait toujours accéder à certaines ressources comme les conversations ou les fichiers partagés. Pour résoudre ce problème, j'ai créé un système de synchronisation qui utilise des événements et RabbitMQ. L'idée était de partager l'information de suppression d'un utilisateur à tous les services concernés en utilisant un flux de messages.

Dans le cas du service de messagerie, cette mise à jour pouvait être traitée directement à la réception de l’événement.. En revanche, pour le service de stockage de fichiers ( Drive ), la logique était plus complexe en raison de l’utilisation des patterns CQRS et Event Sourcing, qui consistent à séparer les opérations de lecture et d’écriture. Il a donc été nécessaire de concevoir un événement capable d’être traité à la fois par les composants responsables de l’écriture des données et par ceux chargés de leur lecture, afin de garantir la cohérence du système.

Enfin, parmi les nombreuses tâches que j’ai effectuées je peux aussi parler de l'ajout d’un champ description dans le service de drive. J’ai d’abord implémenté une zone de saisie permettant à l’utilisateur d’ajouter une description à un fichier ou un dossier. Cette information était ensuite transmise au backend, stockée en base de données, puis récupérée et affichée dans le composant correspondant, permettant ainsi d’enrichir les informations associées aux éléments du drive.

.Revue de Code et peer programming

Après chaque tâche réalisée, je soumettais mon travail en notifiant mon maître d’apprentissage sur mes commits via GitLab. Cela déclenchait une phase d'examen de mon code, pendant laquelle il vérifiait si mon travail était conforme aux normes du projet, si cela était facile à comprendre et si cela était techniquement approprié.

Lorsque des ajustements étaient nécessaires, ces retours donnaient lieu à des échanges constructifs. Dans certains cas, nous travaillions ensemble en peer programming, ce qui me permettait de comprendre plus concrètement les améliorations proposées. Cette approche pédagogique m’a aidé à assimiler les bonnes pratiques de développement, notamment en matière de structuration du code, de lisibilité et d'optimisation. Il arrivait par exemple qu’une implémentation que j’avais réalisée en une dizaine de lignes puisse être simplifiée en seulement quelques lignes.

.Choix des technologies

- Java Spring WebFlux

Dans ce projet, pour le développement back-end , on utilisait Java Spring WebFlux. Spring est un framework très utilisé dans le développement d'applications en Java. Il permet de structurer le code de manière claire et d’accélérer le développement grâce à de nombreux outils intégrés. Dans ce projet, Spring était utilisé pour concevoir les différents services back-end de l’application.

L’utilisation de Spring WebFlux introduit une approche dite “réactive”. Contrairement à un fonctionnement classique où chaque requête est traitée de manière bloquante, le modèle réactif permet de gérer un grand nombre de requêtes de manière asynchrone. Concrètement, cela signifie que le serveur peut traiter plusieurs opérations en parallèle sans attendre la fin de chacune, ce qui améliore les performances et la capacité de montée en charge de l’application.

Ce choix technologique était particulièrement adapté au projet, étant donné la nature distribuée de l’architecture. Les différents microservices devaient communiquer entre eux de manière efficace, tout en étant capables de gérer un grand nombre d’utilisateurs simultanément, notamment pour des fonctionnalités comme la messagerie ou les appels vidéo.

Spring permettait également de structurer les services autour de concepts clairs, comme les contrôleurs pour gérer les requêtes, les services pour la logique métier et les repositories pour l’accès aux données. Cette organisation facilitait la maintenance du code et rendait les différents modules plus lisibles et évolutifs.

Enfin, l’intégration de Spring dans l’écosystème global du projet permettait de construire des services robustes, sécurisés et facilement déployables dans des conteneurs Docker, en cohérence avec l’architecture microservices mise en place.

- MongoDB & PostgreSQL

La gestion des données reposait sur l’utilisation de deux types de bases de données complémentaires : MongoDB et PostgreSQL.

MongoDB est une base de données dite NoSQL (Not only SQL), ce qui signifie qu’elle ne repose pas sur une structure rigide en tables comme les bases de données traditionnelles. Elle stocke les données sous forme de documents, généralement en format JSON. Cette flexibilité la rend particulièrement adaptée à la gestion de données hétérogènes ou évolutives. Dans le cadre du projet, MongoDB était utilisée notamment pour le service de drive, où les données manipulées pouvaient varier en structure, comme des fichiers, des métadonnées ou des informations liées aux contenus stockés.

À l’inverse, PostgreSQL est une base de données relationnelle qui organise les données sous forme de tables structurées avec des relations entre elles. Ce type de base est particulièrement adapté lorsque les données sont bien définies et nécessitent un haut niveau de cohérence. Dans ce projet, PostgreSQL était utilisé pour gérer des informations structurées comme les utilisateurs, les rôles ou les organisations, où l’intégrité des données est essentielle.

L’utilisation combinée de ces deux technologies permettait de tirer parti de leurs avantages respectifs. MongoDB offrait la flexibilité nécessaire pour gérer des données complexes et évolutives, tandis que PostgreSQL garantissait une gestion rigoureuse et fiable des données structurées.

- Docker

L’ensemble des services était déployé et exécuté à l’aide de Docker. Docker est une technologie de conteneurisation qui permet d’isoler une application avec toutes ses dépendances dans un environnement indépendant appelé conteneur.

Concrètement, chaque microservice de l’application, comme le drive, la messagerie ou le service de gestion des utilisateurs, était encapsulé dans son propre conteneur. Cela permettait de garantir que chaque service fonctionne de manière autonome, sans dépendre directement de l’environnement de la machine sur laquelle il est exécuté.

Cette approche présentait plusieurs avantages. Elle facilitait d’abord le déploiement de l’application, car il suffisait de lancer les conteneurs pour recréer un environnement complet et fonctionnel. Elle permettait également d’assurer une cohérence entre les environnements de développement, de test et de production, en évitant les problèmes liés aux différences de configuration.

Docker jouait également un rôle clé dans l’architecture en microservices du projet. En isolant chaque service, il devenait possible de les développer, de les tester et de les mettre à jour indépendamment les uns des autres. Cette modularité contribuait à améliorer la maintenabilité du système et à faciliter son évolution.

L'utilisation de Docker permettait de gérer les ressources de manière efficace et d'optimiser l'exécution des services. Cela simplifiait également la collaboration entre les membres de l'équipe. En effet, chaque membre de l'équipe pouvait disposer d'un environnement identique pour travailler sur le projet.

- React & TypeScript

React est une bibliothèque JavaScript permettant de créer des interfaces utilisateur dynamiques à partir de composants réutilisables. Cette approche, dite “components-based”, consiste à découper l’interface en éléments indépendants, chacun responsable d’une partie spécifique de l’affichage ou du comportement. Cela permet de structurer le code de manière claire et de faciliter la maintenance ainsi que l’évolution de l’application.

Dans le cadre du projet, React était utilisé pour développer les différentes interfaces utilisateurs notamment les services comme le chat, le drive, le calendrier ou encore la gestion des utilisateurs.

TypeScript vient compléter cette approche en apportant un système de typage statiqueau langage JavaScript. Il permet de définir précisément le type des variables, des fonctions ou encore des objets manipulés dans le code. Cette caractéristique est particulièrement utile dans un projet de grande envergure, car elle permet de détecter certaines erreurs dès la phase de développement et d'améliorer la lisibilité du code.

L'association de React et TypeScript permettait ainsi de développer une interface robuste, structurée et plus sécurisée. Elle facilitait également le travail en équipe, en rendant le code plus compréhensible et en limitant les erreurs liées à une mauvaise utilisation des données.

.Outils complémentaires

- Ant Design

Dans le cadre du développement front-end, j’ai utilisé Ant Design, une bibliothèque de composants pour React.

Ant Design est un ensemble de composants prêts à l’emploi permettant de construire rapidement des interfaces modernes. Il propose des éléments tels que des boutons, des formulaires, des tableaux, des fenêtres modales ou encore des systèmes de navigation, déjà stylisés et fonctionnels. Cela évite aux développeurs de devoir créer ces éléments depuis zéro.

Cette bibliothèque permettait d’accélérer le développement tout en garantissant une homogénéité visuelle entre les différentes parties de l’application. Les composants proposés respectent des standards de design et d’ergonomie, ce qui contribue à améliorer l’expérience utilisateur.

Enfin, cette bibliothèque s’intégrait naturellement avec React et TypeScript, ce qui permettait de conserver une structure de code claire et maintenable tout en bénéficiant d’un large éventail de composants réutilisables.

- GitLab et Monday.com

Le versionning du code était assuré via GitLab. GitLab est une plateforme qui permet de stocker le code d’un projet et de suivre son évolution dans le temps. Chaque développeur travaille sur sa propre version du code, appelée branche, afin de développer une fonctionnalité sans impacter directement le reste de l’application. Une fois le travail terminé, les modifications sont proposées pour intégration dans la branche principale, après une phase de relecture appelée revue de code. Ce fonctionnement permet de sécuriser les évolutions, d’éviter les erreurs et de faciliter le travail collaboratif en conservant un historique précis de toutes les modifications.

La gestion des tâches et le suivi du projet étaient réalisés à l’aide de Monday.com. Cet outil permet d’organiser le travail sous forme de tickets correspondant à des fonctionnalités à développer, des corrections à apporter ou des améliorations à réaliser. Chaque tâche est décrite, priorisée et attribuée à un membre de l’équipe, ce qui permet de suivre l’avancement du projet de manière claire. Monday.com facilite ainsi la coordination entre les différents développeurs et offre une vision globale de l’état d’avancement des travaux.

- Auxasuite Web

Enfin, un élément particulier du projet résidait dans le fait que l’ensemble des outils de collaborationutilisés au quotidien étaient directement intégrés à l’application développée par Auxasphere SAS, appelée Auxasuite Web.

En effet, pour organiser les réunions, gérer les échanges entre les membres de l’équipe ou encore partager des documents, nous utilisions les fonctionnalités natives de notre application SaaS.

Cette approche présentait un double intérêt. D'une part, elle permettait de centraliser l'ensemble des outils de travail dans un seul environnement, en cohérence avec l’objectif du produit. D’autre part, elle offrait l’opportunité de tester l'application en conditions réelles d’utilisation, ce qui permettait d’identifier plus facilement d’éventuels problèmes et d’améliorer continuellement les fonctionnalités développées.

L’utilisation quotidienne de la plateforme dans un contexte professionnel constituait ainsi un véritable retour d'expérience, directement exploitable pour faire évoluer le produit et affiner les choix techniques et fonctionnels.

Ce projet avait pour objectif de concevoir une application SaaS complète, capable de centraliser plusieurs outils essentiels au fonctionnement d’une entreprise au sein d’un environnement unique. Lors de mon arrivée chez Auxasphere SAS, l’application était déjà en cours de développement et les principaux services étaient en place. Mon rôle a donc principalement consisté à contribuer à leur amélioration, à corriger des anomalies et à enrichir les fonctionnalités existantes.

Au cours de mon alternance, j’ai pu intervenir sur plusieurs modules de l’application, aussi bien côté front-end que back-end. Ces contributions m’ont permis de participer activement à l’évolution du produit, en apportant des améliorations concrètes sur des services variés tels que le chat, le drive ou encore les appels vidéo. Cette expérience m’a permis de comprendre comment faire évoluer une application existante, en respectant une architecture déjà définie et en garantissant la cohérence du système.

Ce projet a également été l’occasion de travailler dans un environnement professionnel réel avec des contraintes de délais et des objectifs à atteindre. J’ai pu découvrir la gestion du travail en équipe au sein d’une startup, ainsi que l’importance de la communication et de l’organisation pour mener à bien un projet technique.

Il est important de noter que mon alternance n'a pas pu être menée à son terme, en raison de la procédure de liquidation judiciaire qu’à subit l'entreprise. Au moment de cet arrêt, j'étais en train de monter en compétences sur des aspects liés à la mise en production ainsi qu'à l'utilisation d'outils d'analyse de qualité de code comme Sonarqube.

Bien que cette situation ait interrompu la continuité du projet, elle ne remet pas en cause les compétences acquises durant cette période.

Avec du recul, cette expérience reste très enrichissante. Elle m’a permis de développer une véritable autonomie, d’acquérir une vision globale du développement d’une application en microservices et de renforcer mes compétences en développement full stack. J’ai également pu comprendre les enjeux liés à la qualité du code, à la maintenabilité et à l’évolution d’un produit dans un contexte professionnel.

En termes de perspectives, cette expérience constitue une base solide pour la suite de ma carrière de développeur. Grâce à elle, je pourrai aborder de futurs projets avec plus de maturité. Je serai mieux préparé pour gérer les aspects liés à l'architecture, à la collaboration en équipe et à la gestion des contraintes techniques et organisationnelles.