.Développement back-end et API

Antoine Précigout
Rédigé par Antoine Précigout, Directeur Technique
Mis à jour le

Le back-end d'une application est son socle invisible : celui qui porte la logique métier, sécurise les données et garantit les performances. Une API bien conçue détermine ce qui sera (ou ne sera pas) possible de construire au-dessus pendant des années.


Nous concevons des back-ends qui durent : architecture claire, code testé, dépendances maîtrisées, observabilité de bout en bout. Pas de magie, pas d'effet de mode, pas de framework de la semaine.



Nos technologies back-end

  • Node.js / TypeScript : Fastify, NestJS, Express. Idéal pour les API à fort débit et les applications JavaScript full-stack.
  • Python : FastAPI pour les API modernes, Django quand on a besoin d'un framework batteries-included, Celery pour les tâches asynchrones.
  • PHP / Symfony : encore très pertinent pour les applications métier classiques, écosystème mature.
  • Java / Spring Boot : pour les architectures d'entreprise, les besoins de scalabilité ou les contextes très intégrés (SI bancaire, assurance).


Back-end et API

API REST et GraphQL

Une bonne API n'est pas qu'un endpoint qui répond : c'est un contrat documenté, versionné, sécurisé, observé. Nos livrables incluent toujours :


  • Spécification OpenAPI (REST) ou schéma GraphQL, à jour avec le code.
  • Authentification (OAuth 2.0, JWT, API keys) et autorisations fines.
  • Rate limiting, anti-abus, gestion CORS.
  • Pagination, filtrage, tri normalisés.
  • Versionnement et politique de dépréciation.
  • Monitoring : latence, taux d'erreur, traces distribuées (OpenTelemetry).


Architectures événementielles

Pour les SI à fort couplage ou les domaines avec asynchronisme naturel (commande/livraison, événements métier, intégrations partenaires), nous concevons des architectures pilotées par les événements : Kafka, RabbitMQ, AWS SNS/SQS, Redis Streams. Cette approche découple les composants et améliore la résilience, à condition d'être appliquée à bon escient.


Cas concret

HyperMed Online

Sur HyperMed Online (logiciel SaaS de gestion de cabinets médicaux référencé Ségur), nous avons conçu un back-end qui expose le dossier patient, la prescription électronique et les intégrations Pro Santé Connect, DMP et MSSanté. Authentification forte, droits d’accès fins, journalisation conforme aux exigences HDS.
Une API ou un back-end critique à concevoir ? Parlons-en !



L'équipe DINNO derrière ce service

Une équipe permanente à Saint-Herblain, qui suit chaque projet du cadrage à la maintenance.

Aline Deschamps

Aline Deschamps

Directrice Générale, spécialiste Data

Co-fondatrice de DINNO, elle pilote la stratégie de l'agence et accompagne les clients dans la valorisation de leurs données. Elle intervient sur le cadrage des projets, la gouvernance et la dimension métier des solutions, en particulier auprès des acteurs de la santé.

LinkedIn →
Antoine Précigout

Antoine Précigout

Directeur Technique

Directeur technique de DINNO, il pilote l'équipe de développement et garantit la qualité d'ingénierie de bout en bout : architecture, industrialisation, CI/CD, tests automatisés et mise en production. Référent technique sur les projets web et mobiles.

LinkedIn →
Cédric Millauriaux

Cédric Millauriaux

Architecte Logiciel

Architecte logiciel chez DINNO, il intervient sur les audits techniques, la conception d'architecture et l'urbanisation des systèmes d'information. Il accompagne éditeurs et grands comptes dans leurs refontes et leurs choix structurants (cloud, intégration LLM, sécurité).

LinkedIn →

Questions fréquentes

REST ou GraphQL ?
REST reste le défaut raisonnable : largement compris, simple à versionner, bien outillé (OpenAPI, Postman). GraphQL devient pertinent quand les clients consommant l'API ont des besoins variés (mobile, web, partenaires) et que la flexibilité prime sur la lisibilité. Nous concevons les deux, parfois sur la même application (REST pour les opérations CRUD simples, GraphQL pour les requêtes complexes).
Microservices ou monolithe modulaire ?
Pour 80 % des projets, un monolithe modulaire bien architecturé est supérieur aux microservices. Il est plus simple à développer, à déployer, à observer et à faire évoluer. Les microservices se justifient quand l'organisation atteint une taille telle que la coordination devient un problème (typiquement à partir de 30+ développeurs), ou quand certains modules ont des besoins de scalabilité radicalement différents.
Comment gérez-vous la sécurité ?
Threat model dès la conception, OWASP Top 10 dans les revues de code, scanners SAST et DAST en CI, gestion des secrets via Vault ou solutions cloud natives, audits de sécurité réguliers. Pour les projets sensibles (santé, finance), nous mettons en place des contrôles supplémentaires (chiffrement at-rest avec clés gérées, journalisation des accès, anonymisation des environnements de test).

À lire aussi