Développement API REST et GraphQL sur mesure

REST est le bon choix par défaut. Simple, cacheable, compris par tous les développeurs, outillé par API Platform. GraphQL est pertinent dans deux cas précis : votre front-end (surtout mobile) a besoin de requêtes flexibles pour optimiser la bande passante, ou vous avez un graph de données complexe avec des relations imbriquées sur plusieurs niveaux. En pratique, la plupart de nos projets sont en REST. On ne recommande GraphQL que quand le gain est démontré — la complexité supplémentaire (caching plus difficile, N+1 queries côté serveur, courbe d'apprentissage) doit être justifiée par un gain réel côté consommateur.

Ça dépend de la complexité. Une API CRUD simple (quelques ressources, authentification JWT, documentation OpenAPI) se rattache à un premier module sur mesure, à partir de 15 000 € HT. Une API métier avec beaucoup de ressources, logique métier complexe, intégrations tierces, OAuth2 et rate limiting, ou une API publique avec portail développeur, gestion des clés, analytics et versioning, relève d'un projet plus large, à partir de 30 000 € HT. Le chiffrage exact est établi sur devis, en 48 h après un premier échange. Avec API Platform sur Symfony, les coûts sont réduits par rapport à un développement from scratch, grâce à la génération automatique des endpoints CRUD et de la documentation.

Trois niveaux de garantie. Au développement : optimisation des requêtes SQL (eager loading, indexation), cache Redis sur les endpoints les plus sollicités, pagination cursor-based pour les gros volumes. En test : benchmarks de performance avec Artillery ou k6 avant mise en production, objectif de temps de réponse P95 défini contractuellement (typiquement sous 200 ms). En production : monitoring temps réel (Prometheus/Grafana), alertes sur les temps de réponse dégradés, auto-scaling si l'infrastructure le permet. Si un endpoint ne tient pas la charge, on optimise ou on repense l'architecture avant la mise en production.

Oui, c'est un cas fréquent. Une API développée en interne ou par un prestataire précédent, sans documentation, avec des endpoints incohérents et des failles de sécurité. Notre approche : audit technique de l'API existante (1 à 3 jours), rapport avec les points critiques (sécurité, performances, cohérence, documentation), plan d'amélioration progressif. On peut stabiliser l'API existante tout en développant la v2 en parallèle, avec un plan de migration documenté pour les consommateurs.