Compétences
Le développement backend 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 backend 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 backend 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 : champ honeypot, contrôle du temps écoulé, 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.
Je situe mon 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 temps réel à grande échelle, je manque encore de projets récents menés jusqu'à une forte charge de production.
Le backend relie ma spécialisation ERP à mon profil fullstack. Il me permet de ne pas traiter Odoo comme une application isolée : commandes B2B, logistique, courriels, données analytiques et interfaces publiques dépendent de contrats serveur fiables.
Je conseille de commencer une API par son contrat, ses acteurs et ses erreurs avant d'écrire la route heureuse. Il faut savoir qui possède la donnée, quelles validations sont autoritaires, 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.
Atteindre un niveau avancé en consolidant la conception d'API, les transactions, l'observabilité et les tests d'intégration, avec une capacité plus forte à comparer les architectures plutôt qu'à raisonner depuis un seul framework.
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.