Du .NET pour des systèmes conçus pour tourner dix ans
Quand le besoin est une plateforme opérationnelle de longue durée ou une intégration d'entreprise sérieuse, c'est vers .NET que nous nous tournons par défaut : un typage sûr qui tient à mesure que la base de code grossit, des fenêtres de support qui se comptent en décennies. Le raisonnement est détaillé ci-dessous, et il inclut les cas où nous vous orienterions ailleurs.
Réserver un appelNos raisons de le choisir
Des critères d'ingénierie, pas de mode : les mêmes tests que doit passer chaque technologie de notre stack.
Sûreté du typage à l'échelle
Les plateformes opérationnelles atteignent des centaines de milliers de lignes. Le système de types de C# garde cette base de code navigable et laisse le compilateur attraper des classes entières d'erreurs avant qu'elles n'atteignent un entrepôt ou un grand livre comptable.
Un support qui se compte en décennies
Des versions à support long terme, un éditeur qui a un intérêt commercial à la rétrocompatibilité, des systèmes écrits il y a dix ans qui compilent encore aujourd'hui. Pour un logiciel censé survivre à ses auteurs, cet historique compte.
Le vivier de talents là où il compte
L'industrie, la logistique et la finance recrutent des ingénieurs .NET par habitude. Le système reste donc maintenable longtemps après la fin de notre mission, par des gens que vous pouvez réellement recruter.
Une maturité d'intégration d'entreprise
Un outillage de premier ordre pour les ERP, les files de messages, les fournisseurs d'identité et l'archéologie de formats de fichiers dont sont faits les vrais parcs opérationnels. L'essentiel de notre travail d'intégration se joue sur ce terrain.
Les cas où nous le déconseillons
Un choix par défaut n'est digne de confiance que s'il vient avec ses exceptions. Les trois suivantes reviennent le plus souvent.
Des frontends marketing légers
Une page de contenu n'a pas besoin d'un backend compilé. Pour les couches web destinées aux clients, nous nous tournons le plus souvent vers Next.js, souvent posé devant un cœur .NET : chacun fait ce qu'il fait de mieux.
Les pipelines à forte composante ML
L'écosystème du machine learning vit en Python, et lutter contre cela est un mauvais calcul. Pour le travail IA et LLM, nous construisons la couche modèle en Python et gardons .NET pour le système opérationnel qui l'entoure.
Les toutes petites automatisations
Un webhook qui écrit dans un tableur ne mérite pas une architecture de solution. Les petites automatisations se résument souvent à une fonction serverless, et nous le dirons plutôt que de gonfler la facture.
Ce que nous construisons avec .NET
Les formes sous lesquelles le travail .NET arrive le plus souvent, chacune renvoyant au service ou au secteur dont elle relève.
Plateformes opérationnelles →
Gestion des commandes, planification, dispatch et moteurs de tarification : les systèmes sur lesquels une entreprise tourne pendant dix ans.
Modernisation de l'existant →
Remplacement progressif de parcs .NET Framework et VB vieillissants, trop critiques pour être éteints.
Finance et back-office →
Facturation, rapprochement et reporting, là où la justesse est tout l'enjeu.
Ingénierie d'intégration →
Le tissu conjonctif entre des ERP, des CRM et des systèmes d'entrepôt qui n'ont jamais été prévus pour se parler.
Systèmes pour l'industrie →
Planification de production, saisie de données en atelier et flux qualité, face à des logiciels de site à longue durée de vie.
Flux des services financiers →
Onboarding, parcours documentaires KYC et rapprochements, sous pression d'audit et de conformité.
Des exemples, pas une frontière : si le système doit être juste, intégré et encore maintenu dans dix ans, .NET figure probablement sur la liste.
Sa place dans notre méthode
La stack est un résultat du diagnostic, pas une donnée d'entrée. .NET reste un choix par défaut, et un choix par défaut n'est pas un dogme : nous l'écrivons dans notre façon de construire. Si les contraintes de votre système pointent ailleurs, le diagnostic le dira par écrit, avant que quoi que ce soit ne soit construit.
Questions fréquentes
Parlez-vous du .NET moderne ou de l'ancien .NET Framework ?
Les nouveaux systèmes sont construits sur le .NET moderne, multiplateforme. Nous maintenons et modernisons aussi les parcs .NET Framework plus anciens, de façon incrémentale et sans réécriture big bang, parce que chez beaucoup de clients ce système hérité est précisément le problème.
.NET veut-il dire serveurs Windows et licences coûteuses ?
Plus aujourd'hui. Le .NET moderne est open source, gratuit, et tourne dans des conteneurs Linux : nous le déployons sur AWS, GCP ou Azure comme n'importe quelle autre stack. L'ère du tout-Windows sous licence est révolue depuis des années.
Pouvez-vous reprendre notre système .NET existant ?
Oui, après un court audit technique. Le verdict habituel est « garder cette partie, refaire celle-là » : un remplacement progressif (strangler pattern) qui laisse tourner l'ancien système jusqu'à ce que chaque pièce de remplacement fasse ses preuves en production.
Combien de temps prend un projet .NET typique ?
Une v1 ciblée sort généralement en 2 à 3 mois, par jalons, et du logiciel tourne chez vous dès la deuxième semaine. Le diagnostic et le devis, gratuits, en font un chiffre réel pour votre système avant toute signature.
Vous avez une plateforme qui doit durer ?
Le diagnostic est gratuit et la recommandation est écrite, y compris quand la réponse est une autre stack.