Experts Python
FastAPI, Django & IA

La règle est simple. FastAPI pour les APIs pures : async natif, Pydantic v2 pour la validation automatique, doc OpenAPI gratuite, latence 3x inférieure à Django REST Framework sur les endpoints I/O-bound. Django quand vous avez besoin du package complet : admin auto-générée, ORM mature avec migrations, système d'auth complet, et un écosystème de packages qui couvre 90 % des besoins (Celery, Django Channels, DRF). En pratique : si votre projet est une API qui alimente un frontend React ou une app mobile, FastAPI. Si c'est une app web full-stack avec back-office intégré, Django. On ne mélange jamais les deux dans un même projet — c'est un piège de complexité.

Oui, mais il faut connaître les limites. Le GIL (Global Interpreter Lock) empêche le vrai parallélisme CPU en Python. Concrètement : une API FastAPI gère très bien des milliers de requêtes concurrentes grâce à l'async I/O (le GIL ne bloque pas les opérations réseau). Pour le calcul CPU intensif, les librairies comme NumPy et Polars s'exécutent en C/Rust sous le capot — le GIL n'est pas un problème. Pour les jobs lourds (traitement d'images, ML inference), on utilise Celery avec des workers séparés ou multiprocessing. En production, nos APIs FastAPI tiennent des P99 < 50 ms à 3k req/s. Si vous avez besoin de 50k req/s, prenez .NET ou Go. Python n'est pas fait pour ça, et c'est OK.

On commence toujours par le prompt engineering avant de fine-tuner — 80 % du temps c'est suffisant et ça coûte bien moins cher. Phase 1 : POC en 2-4 semaines pour valider que l'IA apporte une vraie valeur métier (pas juste un effet « waouh »). Phase 2 : industrialisation avec pipeline MLOps — versioning des données, entraînement reproductible, tests de non-régression sur les outputs. Phase 3 : déploiement en production avec FastAPI pour le serving, monitoring des drifts et métriques métier (pas juste la précision du modèle, mais l'impact business). Notre stack IA en production : LangChain + RAG avec Pinecone pour les agents conversationnels, scikit-learn pour le ML classique, LangSmith pour l'observabilité. On ne recommande pas les projets IA sans données suffisantes — un modèle sans data, c'est du cargo cult.

Les fourchettes réelles. Le budget dépend de la complexité du projet. API FastAPI métier (auth, CRUD, intégrations) : à partir de 40k EUR. Pipeline data engineering complet (ingestion multi-sources, transformation Polars/dbt, orchestration Airflow, monitoring) : le budget dépend du volume et de la complexité des données. Projet IA avec entraînement et mise en production : le budget dépend des données, des intégrations et de la complexité du modèle. Attention au piège : un projet IA c'est 30 % de code et 70 % de data engineering. Si vos données ne sont pas propres, le budget data prep peut dépasser le budget modèle. On fait un cadrage gratuit d'une semaine pour identifier les vrais coûts avant de s'engager.

uv est notre nouveau standard pour la gestion des dépendances — nettement plus rapide que Poetry, et le lockfile est enfin fiable. En développement : uv avec un pyproject.toml propre et un lock file versionné. En CI/CD et production : Docker avec des images multi-stage (slim ou distroless) pour réduire la taille et la surface d'attaque. On évite les virtualenvs nus en production — c'est Docker ou rien, pour la reproductibilité. Chaque projet a un docker-compose pour le dev local (Postgres, Redis, Mailhog) et des manifests ECS ou Kubernetes pour la production. Les secrets sont dans AWS SSM ou Vault — jamais dans des fichiers .env versionnés. On a vu trop de projets avec des credentials en clair dans Git.

MVP FastAPI (API, base de données, auth, déploiement) : 6 à 10 semaines. Pipeline data engineering complet avec orchestration et monitoring : 8 à 14 semaines. Projet IA avec entraînement et mise en production : 10 à 16 semaines. Ces délais sont réalistes, pas commerciaux — ils incluent le cadrage, les tests et la mise en production. La productivité Python vient de l'écosystème : FastAPI génère la doc et la validation automatiquement, Alembic gère les migrations, pytest + Ruff tournent en CI en moins de 4 minutes. On livre une démo fonctionnelle chaque semaine — si après 3 semaines vous ne voyez rien tourner, c'est qu'il y a un problème.