Service:Service

Développement back-end .NET

APIs REST/GraphQL, back-ends métiers et microservices en Clean Architecture. Tests unitaires et d'intégration systématiques.

Ce que nous livrons

APIs versionnées et documentées (OpenAPI)
Clean Architecture, CQRS, MediatR
Tests unitaires & intégration
Observabilité, logs, metrics

ASP.NET CoreCQRSMediatR

Discuter de ce besoin Voir des réalisations

Un back-end, c'est la partie du logiciel que personne ne voit et que tout le monde subit. Quand il est bien fait, on parle de l'application. Quand il l'est mal, on parle des lenteurs, des chiffres qui se contredisent d'un écran à l'autre, et de la mise en production du vendredi que plus personne n'ose lancer.

Nous écrivons ces back-ends en .NET, surtout en ASP.NET Core. Ce n'est pas un choix d'humeur. C'est une plateforme dont les montées de version majeures se passent sans drame depuis .NET 6, dont les performances sont mesurées publiquement à chaque sortie, et pour laquelle on trouve des développeurs à recruter. Sur cinq ans, ces trois propriétés pèsent plus lourd que l'élégance d'un langage.

Comment nous travaillons

Ce que la Clean Architecture change vraiment

L'idée tient en une phrase : votre logique métier ne doit rien savoir de la base de données, du framework web, ni du fournisseur de mails. Elle est au centre, tout le reste est branché autour. Dit comme ça, c'est de la théorie. Voici ce que ça donne le jour où ça compte : nous avons migré un client de SQL Server vers PostgreSQL en trois semaines, dont deux passées sur les scripts de données. Le code métier n'a pas bougé d'une ligne, parce qu'il ne savait pas quelle base il utilisait.

Le prix à payer est réel et nous le disons : il y a plus de fichiers, plus d'interfaces, et une courbe d'apprentissage de deux à trois semaines pour un développeur qui n'a jamais travaillé ainsi. Sur une application de trois écrans qui ne vivra qu'un an, ce prix n'est pas justifié et nous vous le dirons. Sur un back-end métier qu'on rouvrira pendant huit ans, il est rentabilisé au premier changement d'infrastructure.

CQRS et MediatR, sans le dogme

Séparer les lectures des écritures résout un problème précis : ce ne sont pas les mêmes besoins. Une lecture veut des données agrégées, rapides, souvent dénormalisées. Une écriture veut des règles, des validations et une transaction. Les faire passer par le même modèle oblige à des compromis dont personne ne sort content, et c'est ce qui produit ces entités à quarante propriétés que plus personne n'ose modifier.

MediatR n'est qu'un facteur postal : il porte une requête jusqu'à son gestionnaire. Nous l'utilisons parce qu'il rend les points d'entrée lisibles et qu'il donne un endroit unique où brancher la journalisation, la validation et les transactions. Nous ne l'utilisons pas partout. Sur un CRUD sans règle métier, un appel direct au dépôt est plus court et plus honnête qu'une commande, un gestionnaire et un validateur pour écrire trois champs en base.

Les tests, et ce qu'ils coûtent

Nous visons deux familles de tests et pas une couverture chiffrée. Les tests unitaires couvrent les règles métier, celles qui ont une valeur en euros quand elles se trompent : un calcul de remise, une éligibilité, une règle de facturation. Les tests d'intégration couvrent les frontières, là où ça casse pour de vrai : la base, les appels HTTP sortants, la sérialisation.

Une couverture à 90 % ne veut rien dire si les 10 % restants sont le calcul de TVA. Un chiffre de couverture mesure ce qui a été exécuté, jamais ce qui a été vérifié. Nous préférons une suite de tests plus petite dont on connaît la raison d'être, qui tourne en moins de deux minutes, et que l'équipe lance donc réellement avant de pousser. Une suite de quinze minutes ne sera pas lancée, et c'est ainsi qu'on se retrouve avec une couverture flatteuse et des bugs en production.

Ce qui amène ici

Vos temps de réponse se sont dégradés sans que personne ne sache dire depuis quelle version.
Deux écrans affichent deux totaux différents pour la même donnée, et le débat dure depuis des mois.
Vous devez ouvrir une API à un partenaire et vous n'avez ni versionnement ni documentation.
La mise en production demande une procédure manuelle que seule une personne sait dérouler.

Quand ce n'est pas la bonne prestation

Si vous cherchez à sortir un premier produit en six semaines pour valider une intuition commerciale, cette prestation est trop lourde. Prenez un socle plus direct, quitte à le jeter. Nous préférons vous accompagner à la réécriture dans un an, quand vous saurez ce que le produit doit faire, plutôt que de vous vendre une architecture pour cinq ans sur une hypothèse que le marché n'a pas encore confirmée.

Nous le disons avant de commencer, pas après.

Qualité mesurée

Tests automatisés écrits pendant le développement, pas après. Revue de code obligatoire avant toute fusion, y compris sur les correctifs d'une ligne. Analyse statique branchée sur la CI : si la couverture baisse ou qu'une vulnérabilité connue apparaît, la chaîne s'arrête et personne ne passe outre.

Livraison continue

Un environnement de recette déployé à chaque fusion, une démo à la fin de chaque itération, et un tableau d'avancement que vous consultez quand vous voulez sans avoir à le demander. Les mauvaises nouvelles arrivent tôt, quand il reste du temps pour décider quoi faire.

Transfert de savoir

Nous partons du principe que vous reprendrez la main. Les décisions d'architecture sont écrites et datées, la documentation vit dans le dépôt à côté du code, et vos développeurs travaillent en binôme avec les nôtres s'ils le souhaitent. À la fin, le code, les accès et l'historique vous appartiennent.

Aller plus loin:Service[3]

Un projet en tête ? Donnons-lui vie.

Dites-nous ce que vous cherchez à construire ou à reprendre. Réponse sous 24 heures ouvrées, sans engagement, et un avis franc sur la faisabilité même si la réponse ne nous arrange pas.

Discuter de ce besoin Voir les réalisations