Présentation du projet
WALLIX IAG est une solution de gouvernance des identités et des accès. Son rôle est d’aider les entreprises à piloter les droits des utilisateurs, suivre les mouvements de personnel et sécuriser l’accès à des applications sensibles. J’y ai contribué dans un contexte professionnel réel, avec des enjeux forts de fiabilité, de conformité et de sécurité.
Objectifs, contexte, enjeux et risques
Le projet WALLIX IAG s’inscrivait dans un contexte professionnel réel, au sein d’un éditeur spécialisé en cybersécurité, sur une solution de gouvernance des identités et des accès déjà utilisée par des entreprises. Contrairement à un projet académique ou à un prototype, il ne s’agissait pas de construire un démonstrateur isolé, mais de contribuer à un produit existant, inséré dans un cycle de développement industriel, avec des contraintes fortes de qualité, de sécurité et de continuité de service. Ce contexte changeait profondément la nature du travail attendu, car chaque évolution devait être pensée non seulement pour sa valeur fonctionnelle, mais aussi pour sa compatibilité avec l’existant.
L’objectif principal du projet était de faire évoluer une solution capable d’aider les entreprises à piloter les droits d’accès des utilisateurs, à suivre certains mouvements internes et à sécuriser l’accès à des applications sensibles. Dans ce cadre, mon intervention s’inscrivait dans une logique d’amélioration continue : développement de nouvelles fonctionnalités, correction de bugs, amélioration de comportements existants et participation à la qualité des releases. L’objectif n’était donc pas seulement de produire du code, mais de contribuer à un produit fiable, maintenable et conforme aux exigences attendues dans le domaine de la cybersécurité.
Les enjeux étaient particulièrement élevés. Le premier enjeu était fonctionnel : les évolutions livrées devaient répondre à de vrais besoins d’usage, sans dégrader l’expérience des administrateurs et des utilisateurs. Le deuxième enjeu était technique : toute modification devait s’intégrer proprement dans une architecture déjà en place, en respectant les standards de qualité, de lisibilité et de maintenabilité du produit. Le troisième enjeu était sécuritaire : sur une solution liée à la gestion des identités et des accès, la moindre faiblesse peut avoir des conséquences importantes en matière de confiance, de conformité ou de protection du système d’information. Enfin, un dernier enjeu concernait la chaîne de livraison elle-même, puisque la qualité du produit dépend aussi de la fiabilité des tests, des validations et des processus de release.
Les risques associés au projet étaient donc importants. Le premier risque était la régression fonctionnelle : une évolution utile sur le papier pouvait introduire un comportement indésirable sur une autre partie du produit. Le second risque concernait la dette technique ou les corrections insuffisamment alignées sur l’architecture existante, ce qui aurait pu fragiliser la maintenabilité à moyen terme. Un autre risque portait sur la sécurité et la confiance accordée au produit : dans le domaine de la cybersécurité, une erreur n’est jamais neutre, car elle peut altérer la crédibilité d’une solution pourtant conçue pour protéger. Enfin, il existait aussi un risque organisationnel lié à la coordination entre les différents acteurs du projet car une mauvaise circulation de l’information peut impacter directement la qualité finale de la livraison.
Ma participation au projet
Ma participation a d’abord concerné le développement quotidien du produit. J’ai contribué à l’implémentation de nouvelles fonctionnalités, à la correction de bugs et à l’amélioration de certains comportements existants. Mon travail a porté à la fois sur le front-end en TypeScript Angular et sur le back-end en C# .NET, ce qui m’a demandé de comprendre les flux fonctionnels du produit dans leur ensemble et de mesurer l’impact d’une modification sur plusieurs couches de l’application.
Comme exemple de nouvelles fonctionnalités que j’ai pu totalement créer et implémenter sur le logiciel, il y a les secrets. Ce nouveau module avait pour but de stocker de manière sécurisée les clés ou mots de passe sensibles des administrateurs afin que les intégrateurs puissent les utiliser sur d’autres applications du logiciel sans savoir le contenu réel. Ainsi, grâce à cette fonctionnalité, seuls les administrateurs peuvent voir les informations sensibles tout en les partageant aux autres métiers.
Voici la gestion d’un secret côté administrateur :
Voici l’utilisation d’un secret côté intégrateur :
Une part importante de mon activité a consisté à analyser les tickets avant de passer au développement. Cette étape supposait de comprendre précisément le besoin, de reproduire les anomalies, d’identifier leur origine probable puis de proposer une solution cohérente avec l’architecture existante. Ce travail d’analyse m’a appris qu’en environnement professionnel, la qualité d’un correctif dépend autant de la justesse du diagnostic que de l’écriture du code lui-même.
J’ai également participé aux revues de code. Ces échanges techniques m’ont permis de confronter mes choix à ceux de développeurs plus expérimentés, d’améliorer progressivement la qualité et la maintenabilité de mes développements, et d’intégrer les standards de l’équipe. La revue de code n’était pas seulement une étape de contrôle : elle constituait un véritable espace d’apprentissage sur la qualité attendue dans un produit de cybersécurité.
Par la suite, j’ai pris une responsabilité plus marquée sur la phase de sécurisation des releases. J’ai testé l’application de manière approfondie avant la sortie de nouvelles versions, afin d’identifier d’éventuelles régressions et de vérifier la stabilité des évolutions livrées. J’ai aussi participé à la mise en place d’un pipeline de signature des installeurs, dans le but de fiabiliser le processus de livraison. Cette mission a été particulièrement formatrice, car elle reliait directement le développement à la confiance que le client peut accorder à la chaîne de déploiement du produit.
Au-delà des tâches purement techniques, j’ai dû maintenir une attention constante à la cohérence globale du produit. Intervenir sur une solution déjà exploitée par des entreprises implique de ne jamais considérer une évolution comme isolée : chaque correction, chaque amélioration et chaque livraison doit être pensée dans son impact sur l’existant, sur les usages réels et sur la stabilité générale de la plateforme.
Acteurs et interactions
Le projet mobilisait plusieurs interlocuteurs : développeurs, QA, support, PM, consultants et parfois des clients ou représentants métier. J’ai donc dû adapter ma communication selon les sujets, en passant d’un échange très technique à des retours davantage orientés qualité, usage ou compréhension du besoin.
Cette dimension collective a été déterminante dans ma progression. Le produit ne dépendait pas d’une seule contribution isolée, mais d’une coordination continue entre développement, validation et compréhension métier. Travailler dans cet environnement m’a appris à mieux situer ma contribution dans un cycle de vie logiciel complet.*
Résultats obtenus
Pour l’équipe et pour l’entreprise, mon apport s’est traduit par des évolutions fonctionnelles livrées dans un cadre plus sûr, des corrections de bugs utiles au produit et une participation active à la qualité des releases. Le pipeline de signature a également renforcé la fiabilité du processus de mise à disposition des installeurs.
Cette expérience professionnelle m’a permis de faire évoluer considérablement mon niveau de compétence. J’y ai gagné en rigueur, en compréhension du cycle de vie d’un produit logiciel critique et en capacité à travailler dans un environnement industriel exigeant.
Les lendemains du projet
Cette expérience a renforcé mon intérêt pour la cybersécurité, pour la qualité logicielle et pour les environnements qui nécessitent une forte exigence. En tant qu’alternant, j’ai pu y développer à la fois des compétences techniques et des compétences humaines liées à la collaboration, à la rigueur et à l’autonomie.
Mon souhait est désormais orienté vers la poursuite de mon parcours dans un environnement de ce type, avec l’ambition de contribuer durablement à des produits exigeants. Cette expérience nourrit également mon projet d’évolution vers un poste de développeur full-stack sénior, avec à terme une dimension managériale.
Mon regard critique
C’est le projet sur lequel ma valeur ajoutée a été la plus forte, car j’ai pu intervenir à la fois sur le développement, la validation et la sécurisation des livraisons. Avec du recul, j’aurais toutefois gagné à formaliser davantage certains apprentissages techniques au fil du temps. Dans un environnement où plusieurs problématiques reviennent de manière récurrente, une documentation plus systématique des cas rencontrés, des solutions apportées et des points de vigilance aurait permis de capitaliser encore plus efficacement sur l’expérience acquise.
Je retiens aussi de ce projet une transformation dans ma manière de juger la qualité d’un développement. En environnement académique, l’attention se porte souvent sur ce qui a été réalisé. En contexte professionnel, j’ai compris qu’une évolution logicielle se juge aussi à sa capacité à préserver la stabilité de l’existant, à limiter les régressions et à s’intégrer proprement dans une architecture déjà en production. Cette prise de conscience a profondément modifié ma perception du développement logiciel et de la responsabilité associée à chaque modification.
Mon regard critique porte également sur ma progression personnelle. Entre ma première et ma troisième année chez WALLIX, l’évolution la plus marquante a concerné mon autonomie. J’ai progressivement appris à mieux comprendre le produit, à intervenir avec plus d’assurance et à assumer des tâches plus transversales. Pour autant, cette progression appelle une exigence nouvelle : aller au-delà de l’exécution technique pour mieux formaliser, transmettre, anticiper et contribuer avec davantage de recul sur l’organisation globale du produit et des processus.
Enfin, ce projet a eu une portée déterminante dans la construction de mon identité professionnelle. Il a confirmé mon intérêt pour les environnements à forte exigence et m’a montré que la valeur d’un développeur ne se mesure pas seulement à la quantité de code produit, mais à la fiabilité qu’il apporte à l’ensemble du cycle de vie logiciel. Ce regard critique est donc celui d’une expérience réussie, mais surtout d’une expérience qui a élevé mon niveau d’exigence envers moi-même et envers la qualité attendue dans un produit en production.