Compétences
Le développement back-end couvre les traitements exécutés côté serveur : règles métier, accès aux données, authentification et autorisation, API, tâches planifiées, intégrations externes et observabilité. Une route qui renvoie une réponse correcte n'est qu'une partie du travail. Il faut définir les données acceptées, valider les entrées, préserver les invariants, gérer les erreurs, protéger les secrets, contrôler les effets de bord et rendre le comportement testable.
Ma pratique ne se limite pas à un seul langage. J'utilise Python avec l'ORM Odoo pour les processus ERP, PHP et Symfony sur le site B2B, Node.js avec Express, Prisma et PostgreSQL pour CAP2vie, ainsi que les Server Actions de Next.js pour le portfolio. Cette diversité m'a appris à reconnaître les mêmes responsabilités derrière des outils différents : contrat d'échange, transaction, contrôle d'accès, résilience et traçabilité.
Je porte une attention particulière aux intégrations. Lorsque deux systèmes échangent des clients, produits, commandes ou courriels, une disponibilité apparente ne prouve pas que les données sont complètes et cohérentes. Je vérifie donc le format, les erreurs, les reprises, les doublons possibles et la responsabilité de chaque système.
Symfony 8.0.0 est devenu stable le 27 novembre 2025, accompagné de ses nouveautés et d'un guide de mise à niveau. Cette sortie majeure rappelle qu'un back-end maintenable demande des tests, le traitement progressif des incompatibilités et une stratégie de migration.
Consulter la source : SymfonyLe site B2B Symfony dépend des clients, produits, stocks et commandes gérés dans Odoo. Lorsque les mécanismes standard ne répondaient pas exactement au contrat nécessaire, j'ai développé des contrôleurs ciblés dans les modules internes. Je devais sélectionner les données utiles, respecter les droits, éviter d'exposer des informations confidentielles et conserver une frontière claire entre le domaine de l'ERP et celui du site. La migration vers Odoo 19 a ensuite imposé d'adapter la majorité des échanges vers JSON-2 et de vérifier les flux dans les deux sens.
Résultat — Le site B2B et les intégrations principales ont repris leur fonctionnement après la migration. Les routes sur mesure restent localisées dans des modules versionnés, ce qui rend leur responsabilité et leur évolution identifiables.
Pour CAP2vie, l'équipe a construit un back-end JavaScript avec Express, PostgreSQL et Prisma. Nous avons défini les principales entités du questionnaire, stocké les réponses et associé les événements aux dimensions de trajectoire. En cours de projet, j'ai pris le lead sur l'interconnexion multiécrans avec Socket.io : création d'une room identifiée et protégée par mot de passe, synchronisation de l'état nécessaire au second écran et maintien de la saisie lorsque l'affichage secondaire se déconnectait. Le prototype restait local et la reconnexion était encore manuelle, limites que nous avons documentées.
Résultat — La démonstration multiécrans a fonctionné et le développeur suivant a réussi à installer le projet. L'expérience m'a appris à raisonner sur l'état d'une connexion temps réel, ses interruptions et le périmètre de sécurité acceptable uniquement pour une preuve de concept contrôlée.
Le formulaire du portfolio utilise une Server Action Next.js qui revalide les données avec Zod avant d'appeler Resend. J'ai ajouté plusieurs couches contre les soumissions indésirables : un champ honeypot, un contrôle du temps écoulé, une limitation à cinq requêtes par heure et par adresse IP, puis reCAPTCHA v3 lorsqu'il est configuré. Le navigateur ne décide jamais seul de la validité. Les réponses d'erreur restent génériques pour l'utilisateur tandis que les tests simulent les dépendances externes afin de couvrir les embranchements sans envoyer de vrais courriels.
Résultat — La chaîne d'envoi a été validée par mes essais et dispose de tests sur la validation et les protections principales. Je conserve néanmoins une limite explicite : les services externes sont simulés dans les tests automatisés et méritent encore des scénarios d'intégration plus proches du déploiement réel.
Les éléments de preuve décrivent des épisodes précis. Cette synthèse les replace dans les études de cas complètes : le contexte, ma contribution et le résultat permettent d'observer ce que cette compétence a rendu possible, avec le niveau de prudence nécessaire sur chaque résultat.
J'estime avoir un niveau intermédiaire. Je sais concevoir des modèles, des règles métier, des API et des intégrations dans plusieurs écosystèmes, puis les tester et les déployer. Mon expérience la plus profonde reste Odoo ; sur Symfony, l'architecture distribuée et les systèmes en temps réel à grande échelle, je manque encore de projets récents menés jusqu'à une forte charge de production.
Je conseille de commencer une API par son contrat, ses acteurs et ses erreurs avant d'écrire le scénario nominal. Il faut savoir qui possède la donnée, quelles validations font autorité, comment l'appel peut être rejoué et quelle trace permettra de diagnostiquer un échec. Les contrôles d'interface complètent cette protection, mais ne remplacent jamais ceux du serveur.
Je poursuis la pratique de Symfony sur le B2B, l'approfondissement de PostgreSQL et la conception des intégrations JSON-2. Le projet de Business Intelligence connecté à Odoo doit aussi me faire travailler les pipelines de données, la reprise sur erreur et la séparation entre lecture analytique et transactions ERP.
