FastAPI ou Django : lequel pour votre projet ?
Django REST Framework reste mon choix quand le projet a besoin d'un back-office, d'utilisateurs, de permissions et de nombreux modèles : c'est ce que j'ai utilisé pour Pitchichi et pour la première plateforme de ScienceProtect. FastAPI est plus adapté aux services ciblés, asynchrones et fortement typés : l'API qui interroge PubMed pour ScienceProtect, celle qui relaie les formulaires de contact de mes sites vitrine, ou celle de TapToSupport, une application de dons pour associations.
Dans les deux cas, je travaille avec un typage strict vérifié par mypy, un lint automatique et des tests qui tournent à chaque demande de fusion.
Les intégrations que je connais déjà
Envoi d'e-mails transactionnels par Brevo, avec les pièges vérifiés en production : saisies échappées dans le HTML du message, pièces jointes limitées aux formats acceptés, quota d'envoi protégé par une limitation de débit par visiteur et un champ piège contre les robots. Paiement avec Stancer, réécrit à partir de sa spécification OpenAPI officielle pour Eco-Actives, et avec Stripe Connect pour TapToSupport. Données publiques avec PubMed et les avis d'experts de l'EFSA pour ScienceProtect, ou l'open data ferroviaire.
Quand un service tiers documente mal son comportement, je le vérifie contre une vraie instance. Sur Eco-Actives, trois écarts entre la documentation des webhooks Saleor et leur comportement réel ont été trouvés ainsi et corrigés.
Récupérer et structurer des données
Une partie de mon travail consiste à aller chercher des données là où elles sont, puis à les rendre exploitables : scrapers des experts et avis de l'EFSA, ingestion de publications PubMed avec respect des quotas de l'API, reconstitution des trajets à partir des jeux open data de la SNCF, tâches de fond planifiées avec Celery ou TaskIQ. Les données atterrissent dans PostgreSQL ou dans un graphe Memgraph, avec des migrations versionnées.
Je respecte les conditions d'utilisation des sources et les quotas qu'elles imposent : une API qui se fait bannir n'est utile à personne.
Tests et déploiement
L'API de contact d'Antiquité Mallarmé compte 27 tests pour un seul formulaire, parce que ce formulaire est le premier geste de conversion du site : limitation de débit, champ piège, photos trop lourdes, numéro de téléphone mal saisi, panne de Brevo. Chaque API que je livre passe par un vrai build Docker, un démarrage du conteneur et un appel réel des points d'entrée avant d'être considérée comme terminée.
Le déploiement suit le même schéma sur tous mes projets : une image construite par GitLab CI, poussée dans le registre, déployée par environnement derrière Traefik avec HTTPS automatique, et des secrets qui ne passent jamais par le dépôt de code.
Un exemple : l'API de TapToSupport
TapToSupport est une application qui permet aux associations de collecter des dons en personne, par paiement sans contact sur téléphone. Avant d'écrire l'API, j'ai comparé quatre prestataires de paiement et choisi Stripe Connect, qui permet à chaque association de créer son compte seule. L'API FastAPI isole ce prestataire derrière une interface : aucun autre module n'importe la bibliothèque Stripe, ce qui permettra d'en changer sans réécrire le reste.
Le donateur n'a ni compte ni mot de passe : il reçoit un lien signé à usage unique par e-mail, envoyé par Brevo, et son reçu fiscal est généré en PDF. La migration de la base de données a été vérifiée dans les deux sens sur PostgreSQL, et les pièges rencontrés (types énumérés qui survivent à une suppression de table, dépendances système du générateur de PDF sur Alpine) sont documentés dans le dépôt pour ne pas être redécouverts. Le projet est en cours : l'API existe, le site et l'application mobile suivront.
J'écris aussi le contrat d'une API avant son code quand plusieurs personnes doivent travailler en parallèle : c'était le cas pour l'API d'Arbre Agile, dont le contrat OpenAPI précédait l'implémentation.
Pourquoi Python ?
Python est le langage que j'utilise au quotidien depuis mes premiers projets jusqu'aux services de 2026. Il a l'écosystème le plus riche pour les données, l'IA et le scraping, des frameworks web éprouvés, et il se lit facilement, ce qui compte pour un code qu'une autre personne devra reprendre. Je contribue aussi à l'écosystème : j'ai proposé plusieurs améliorations fusionnées dans neontology, une bibliothèque open source de modélisation de graphes en Python.
Travailler en renfort de votre équipe
Je peux prendre en charge un service complet ou renforcer une équipe existante. J'ai travaillé plus de deux ans dans une grande équipe pour la SNCF, sur des services Python et leur outillage de déploiement, et au sein d'équipes de quelques personnes pour ScienceProtect ou Pitchichi. Je m'adapte à vos conventions de code et à votre processus de revue.
Je ne fais pas de développement Java, .NET ou PHP : si votre système est bâti là-dessus, je vous orienterai vers quelqu'un de plus pertinent.
