Dot.Blog

NDepend 2027 : quand l'IA s'attaque véritablement à la dette technique de nos applications .NET

odahan@e-naxos.com — mar., 3 nov. 2026 11:00:00 +0000

L'intelligence artificielle sait désormais produire du code, et parfois beaucoup de code. Mais peut-elle nous aider à améliorer de manière fiable les millions de lignes que nous avons déjà écrites ? Avec NDepend 2027 et son approche NDepend.AI, l'éditeur propose une réponse particulièrement intéressante : associer la puissance des agents de programmation comme Claude ou Codex à la rigueur de l'analyse statique, de la compilation et des tests. Une évolution majeure qui pourrait bien changer notre manière d'aborder la dette technique.

De l'analyse de code à l'amélioration assistée par l'IA

J'ai régulièrement eu l'occasion de parler de NDepend sur ce blog. C'est un produit que les développeurs .NET connaissent souvent de nom, même s'ils n'ont pas toujours eu l'occasion d'en explorer toutes les possibilités.

Historiquement, NDepend s'est construit autour d'une idée simple, mais exigeante : mesurer objectivement la qualité d'une base de code .NET et fournir aux développeurs les moyens de comprendre ses faiblesses.

Complexité, couplage, dépendances, couverture des tests, architecture, violations de règles, estimation de la dette technique : le produit offre depuis longtemps une richesse d'analyse considérable.

Et cette richesse est précieuse.

Car lorsqu'on intervient sur une application professionnelle qui existe depuis dix ou quinze ans, la difficulté n'est pas uniquement de comprendre une méthode ou de corriger un bogue. Il faut comprendre une architecture, mesurer les risques, distinguer les problèmes réellement importants des anomalies secondaires et décider où investir les efforts de maintenance.

NDepend excelle dans cette discipline.

Avec la version 2027, l'éditeur franchit cependant une étape supplémentaire.

L'analyse ne constitue plus seulement le résultat d'un diagnostic : elle devient le point de départ d'un processus de correction assisté par des agents IA.

C'est une différence considérable.

Les agents IA ont besoin d'un instrument de mesure

Pour bien comprendre l'intérêt de cette évolution, il faut revenir sur une faiblesse des assistants de programmation actuels.

Claude Code, Codex et les autres agents modernes sont devenus capables d'examiner des projets, de modifier plusieurs fichiers, de lancer des compilations et d'exécuter des tests.

Ils peuvent accomplir des travaux de refactoring impressionnants.

Mais leur capacité à produire du code ne signifie pas qu'ils disposent spontanément d'une vision fiable de la qualité architecturale d'une application.

Un agent peut corriger une méthode complexe sans nécessairement mesurer les conséquences de sa modification sur le couplage entre composants. Il peut simplifier du code tout en dégradant la couverture des tests. Il peut également éliminer un problème local en introduisant une dépendance architecturale indésirable.

En d'autres termes, produire une modification et démontrer qu'elle constitue une amélioration sont deux opérations différentes.

C'est là qu'intervient NDepend.

L'outil dispose déjà d'un moteur d'analyse statique, de règles personnalisables, de métriques de complexité, d'informations de couverture et de mécanismes permettant de comparer l'état d'une application avant et après modification.

L'idée de NDepend.AI consiste à utiliser ces capacités pour guider et évaluer le travail des agents de programmation.

Plutôt que de demander simplement à l'IA de « rendre le code meilleur », on peut lui soumettre des problèmes identifiés et disposer d'indicateurs pour apprécier le résultat.

On ne se contente plus d'une réponse plausible : on cherche une amélioration mesurable.

NDepend.AI : le meilleur de deux mondes

L'une des diapositives de la présentation de NDepend 2027 résume parfaitement cette philosophie sous le titre Best of both worlds.

Elle oppose deux familles d'outils.

D'un côté, la compilation, les tests et l'analyse statique. Ces outils sont déterministes, rapides, relativement peu coûteux à exécuter et ne consomment pas de tokens. En revanche, leurs possibilités dépendent des règles et des mécanismes de vérification disponibles.

De l'autre, les agents de programmation. Ils sont capables d'interpréter des demandes complexes, de proposer des transformations et de traiter des problèmes pour lesquels aucun correctif automatique classique n'a été prévu.

Mais ils sont également non déterministes, potentiellement plus lents et plus coûteux à utiliser.

L'idée consiste donc à faire travailler les deux approches ensemble.

Les outils déterministes mesurent, vérifient et orientent. L'agent IA interprète, propose et réalise les transformations.

Ce positionnement me paraît particulièrement pertinent.

Il évite l'un des travers fréquents de l'IA générative : lui demander de remplacer des outils spécialisés alors qu'elle peut obtenir de bien meilleurs résultats en s'appuyant sur eux.

NDepend ne cherche pas à réinventer le compilateur, le moteur de tests ou l'analyse statique à l'aide d'un LLM. Il utilise leurs résultats pour encadrer le travail de ce dernier.

Claude, Codex et les autres : l'intérêt d'une approche ouverte

Un autre aspect important de cette évolution est la volonté de travailler avec des agents de programmation externes.

L'intérêt n'est pas d'imposer un modèle de langage particulier, mais de permettre à l'outillage NDepend de participer à un environnement de développement dans lequel l'agent IA joue un rôle actif.
C'est d'autant plus intéressant que les outils évoluent à une vitesse considérable.
Claude Code, Codex, Copilot et leurs concurrents proposent des approches et des capacités qui changent régulièrement. Enfermer une solution d'analyse de code dans un assistant unique constituerait donc un choix assez restrictif.

NDepend avait déjà entrepris ce rapprochement avec l'IA en proposant son serveur MCP open source.
Le protocole MCP permet à un agent compatible d'accéder à des fonctionnalités externes à travers des outils structurés.

Il devient ainsi possible d'exposer les résultats des analyses NDepend à un assistant de programmation, de lui faire interroger des métriques, explorer des dépendances ou obtenir des informations sur les problèmes détectés.

Avec NDepend 2027, cette intégration prend une dimension plus opérationnelle.

L'objectif ne consiste plus seulement à fournir des informations à l'agent, mais à organiser un véritable travail de correction et à en présenter les résultats.

Pour les équipes qui utilisent déjà des agents IA, l'intérêt est évident : elles peuvent conserver leurs habitudes et leurs outils de programmation tout en bénéficiant de l'expertise d'un analyseur spécialisé.

La correction par itérations : un processus plutôt qu'un simple prompt

La démonstration de NDepend 2027 présente un mécanisme particulièrement intéressant : les Fix Rounds, autrement dit des cycles successifs de correction.

Le principe est relativement simple.

Une analyse identifie un ensemble de problèmes. L'agent entreprend des corrections, puis les outils de vérification permettent d'en évaluer les résultats. Les problèmes restants peuvent alors alimenter de nouvelles itérations.
L'interface de NDepend.AI conserve une trace de ce processus.

On y retrouve notamment les différentes passes de correction, les problèmes résolus, ceux qui subsistent, les modifications réalisées et des informations sur les validations effectuées.

Ce n'est pas un détail.

Lorsque l'on confie une opération de maintenance à un agent, la question n'est pas seulement de savoir s'il a terminé sa tâche. Il faut pouvoir déterminer ce qu'il a changé, pourquoi, avec quels résultats et quelles difficultés éventuelles. La présentation que je vous invite à visionner (je ne vais pas tourner un doublon pour cet article) montre justement un suivi de ces opérations, ainsi qu'un bilan indiquant les problèmes traités et ceux qui demeurent. Cette visibilité contribue à transformer une succession d'actions IA en un processus plus contrôlable.

Et elle répond à une vraie difficulté des workflows agentiques : conserver une trace exploitable de l'évolution du travail au fil des itérations.

Une démonstration concrète sur Jellyfin

La vidéo de présentation utilise notamment Jellyfin, le serveur multimédia open source développé en .NET.
Le choix est intéressant, car on ne se trouve pas face à une petite application artificielle créée pour les besoins d'une démonstration.
Jellyfin constitue une base de code suffisamment importante pour illustrer des problèmes représentatifs de projets réels.
La démonstration montre plusieurs catégories d'interventions.

On observe des corrections touchant à des problèmes de qualité du code, mais également des questions de sécurité.
Un exemple visible concerne notamment une comparaison de codes PIN, avec l'introduction d'une comparaison en temps constant à l'aide de CryptographicOperations.FixedTimeEquals.

C'est un exemple parlant.

La question n'est pas simplement de satisfaire un analyseur en modifiant quelques lignes de code. Il s'agit de traiter un problème susceptible d'avoir des implications sur la sécurité de l'application.
La démonstration montre également des modifications accompagnées de mesures de couverture et d'informations sur les tests.

Autrement dit, l'outil ne se limite pas à compter les avertissements supprimés. Il met également à disposition des informations permettant de replacer la correction dans son contexte technique.

C'est une orientation essentielle pour envisager l'utilisation de l'IA sur du code destiné à la production.

Mesurer les corrections, mais aussi leurs conséquences

L'une des difficultés du refactoring assisté par IA réside dans l'évaluation du résultat.
Supposons qu'un agent fasse disparaître cinquante violations d'une règle.
Peut-on considérer que son travail est terminé ?

Pas nécessairement.

La modification a peut-être introduit une régression, dégradé un autre indicateur ou simplement déplacé le problème.
NDepend dispose ici d'un atout considérable : sa capacité historique à comparer des analyses et à mesurer l'évolution d'une base de code.
La nouvelle interface AI Assistant exploite cette richesse à travers plusieurs vues.

On retrouve notamment :

Fix Rounds, pour suivre les passes successives de correction ;
Summary, pour disposer d'un bilan des opérations ;
Architecture, pour examiner les conséquences architecturales ;
Change Log, pour consulter les modifications intervenues ;
Fixes Details, pour explorer les corrections en détail.

La démonstration présente également des vues de différences entre le code initial et le code modifié, avec les règles associées, les problèmes corrigés et les problèmes encore présents.
Ce rapprochement entre les modifications du code source et les résultats de l'analyse constitue une amélioration importante de la traçabilité.
Il devient possible d'examiner une correction sous plusieurs angles : le code modifié, la violation traitée, les métriques obtenues et les conséquences sur l'application.

C'est précisément le type de visibilité dont on a besoin lorsqu'on commence à confier des interventions significatives à des agents IA.

Les Quality Gates : définir ce que signifie « terminé »

Une autre fonctionnalité mérite une attention particulière : les Quality Gates.

Le concept n'est évidemment pas nouveau dans NDepend.
Depuis longtemps, le produit permet de définir des conditions de qualité destinées à être vérifiées lors de l'analyse d'une application. Ce qui devient intéressant avec l'automatisation par IA, c'est la possibilité d'utiliser de telles conditions comme critères d'évaluation du travail de correction. Car un agent a besoin d'un objectif.

Lui demander de corriger « autant de problèmes que possible » est une instruction vague, susceptible de produire des modifications nombreuses et difficilement maîtrisables. À l'inverse, définir précisément les catégories de problèmes à traiter et les critères d'acceptation permet de mieux encadrer son intervention. La démonstration montre notamment un mécanisme de contrôle pouvant porter sur l'état des Quality Gates et le nombre de problèmes subsistant après les corrections.

Cela ouvre des perspectives intéressantes pour la maintenance des applications.

On peut imaginer des campagnes ciblées sur certaines familles de violations, avec des objectifs mesurables et une validation systématique des résultats. Il ne s'agit évidemment pas de donner carte blanche à un agent pour modifier sans contrôle une application entière. Il s'agit de disposer des instruments nécessaires pour lui confier un périmètre de travail défini, tout en conservant une capacité d'évaluation indépendante de ses propres affirmations.

La nuance est importante.

La couverture des tests, indispensable à une IA réellement utile

La démonstration accorde également une place importante à la couverture de code.

C'est loin d'être anecdotique.

Un agent peut produire une modification syntaxiquement correcte, compilable et même apparemment raisonnable. Mais s'il modifie le comportement d'une méthode sans que celui-ci soit suffisamment testé, il devient beaucoup plus difficile de garantir l'absence de régression. L'intégration des informations de couverture dans les résultats NDepend apporte donc un éclairage précieux.
Dans les vues de comparaison présentées, on peut observer l'évolution de la couverture d'éléments modifiés ainsi que les tests associés.
La présentation illustre notamment des situations dans lesquelles une portion de code initialement peu couverte bénéficie ensuite d'une couverture complète.

Attention toutefois à ne pas confondre couverture et qualité des tests : atteindre 100 % de couverture ne constitue jamais une preuve de correction fonctionnelle. Cela reste néanmoins un indicateur important pour une démarche de modernisation assistée par IA. Et surtout, l'association de la compilation, des tests, de l'analyse statique et des agents de programmation constitue une méthode bien plus crédible que la simple génération de correctifs à partir d'un prompt.

Le retour en grâce des règles et du déterminisme

Il y a un aspect presque paradoxal dans cette évolution.

Depuis l'arrivée de l'IA générative, certains discours pourraient laisser penser que les règles statiques, les métriques traditionnelles et les méthodes formelles de contrôle sont appelées à devenir secondaires.

La démarche de NDepend démontre plutôt le contraire.

Plus nous confions la production de code aux IA, plus nous avons besoin d'outils indépendants pour en mesurer la qualité.

Lorsque le développeur écrit lui-même une modification, il dispose au moins d'une connaissance directe de ses intentions et des choix techniques effectués.

Avec un agent, cette relation change.

Le développeur définit un objectif, supervise une exécution et examine un résultat qui peut comporter de nombreuses modifications. La nécessité de disposer de contrôles objectifs devient alors encore plus forte. De ce point de vue, les outils comme NDepend ne perdent pas leur pertinence avec l'arrivée de l'IA. Ils en gagnent probablement.

L'analyse statique, les contraintes architecturales, les tests et les Quality Gates constituent autant de mécanismes permettant de conserver la maîtrise d'un processus de développement de plus en plus automatisé.

C'est un changement de perspective particulièrement intéressant.

Une nouvelle manière d'aborder les projets de modernisation .NET

Cette évolution me paraît particulièrement prometteuse dans le domaine des migrations et de la réduction de la dette technique.

De nombreuses entreprises disposent d'applications .NET qui ont traversé plusieurs générations technologiques. Elles contiennent souvent des choix architecturaux anciens, des dépendances difficiles à démêler, des composants insuffisamment testés et une dette accumulée au fil des années. La difficulté consiste rarement à identifier quelques problèmes isolés.

Le véritable enjeu est d'organiser une amélioration progressive, sans perdre la maîtrise des risques.

C'est précisément dans ce contexte que l'association entre NDepend et les agents IA prend tout son sens. NDepend peut aider à identifier les points sensibles, à analyser les dépendances et à quantifier les problèmes. L'agent peut prendre en charge une partie du travail de transformation. Les compilations, les tests et les analyses successives permettent ensuite d'évaluer les résultats. Et les développeurs conservent la responsabilité des choix d'architecture, des arbitrages et de la validation finale. Ce n'est pas une solution magique qui effacerait automatiquement quinze ans de dette technique.

Mais c'est une approche cohérente pour industrialiser une partie du travail de maintenance, à condition de disposer de règles pertinentes et d'une stratégie de tests sérieuse.

Mon avis : NDepend prend une direction particulièrement pertinente

Ce qui me plaît dans cette évolution n'est pas simplement la présence de l'IA.

Aujourd'hui, presque tous les outils de développement affichent une fonction IA quelque part dans leur interface. Cela ne suffit plus à constituer une innovation.

Ce qui compte, c'est la manière dont cette technologie est utilisée.

Avec NDepend.AI, l'éditeur cherche à résoudre un problème concret : comment exploiter la puissance des agents de programmation pour réduire la dette technique tout en conservant des moyens objectifs de contrôler leur travail ?

Et cette démarche repose sur une idée que je trouve particulièrement saine : ne pas demander au modèle de langage de tout faire. Le laisser intervenir là où il excelle, c'est-à-dire dans la compréhension des intentions et la transformation du code. Mais confier la mesure, les contraintes et une partie de la validation à des outils déterministes spécialisés. On obtient ainsi une collaboration entre plusieurs formes d'intelligence logicielle, plutôt qu'une dépendance exclusive aux capacités d'un LLM.

Pour les architectes et les responsables techniques, cette distinction est fondamentale.

Elle permet d'envisager une utilisation plus sérieuse des agents IA, notamment sur des applications existantes dont la qualité doit être améliorée sans mettre en péril leur fonctionnement. Bien entendu, ces mécanismes ne dispensent ni des revues de code ni des tests fonctionnels. Ils ne garantissent pas non plus qu'une transformation soit architecturalement judicieuse simplement parce qu'elle satisfait une règle. Mais ils constituent un progrès significatif dans la capacité à encadrer, mesurer et expliquer les interventions d'agents IA.

Et c'est précisément ce qui rend cette nouvelle orientation intéressante.

Conclusion : NDepend 2027, bien plus qu'une évolution cosmétique

Avec NDepend 2027, l'éditeur présente une évolution ambitieuse de son produit.

L'outil conserve ses qualités historiques d'analyse du code, de mesure de la dette technique et de contrôle architectural. Mais il leur ajoute désormais une dimension opérationnelle, en les associant aux agents de programmation modernes.

La possibilité de conduire des corrections successives, de mesurer leurs effets, de suivre les modifications et de les évaluer au regard de critères de qualité transforme profondément les perspectives d'utilisation du produit.

NDepend ne se contente plus d'expliquer pourquoi notre code mérite d'être amélioré : il contribue à organiser et à contrôler le travail des agents chargés de l'améliorer.

À mes yeux, c'est une évolution autrement plus importante qu'un assistant conversationnel ajouté à une interface existante.

Et c'est peut-être également une illustration de ce que sera progressivement le développement assisté par IA : des agents capables d'intervenir sur le code, épaulés par des outils spécialisés qui apportent les mesures, les contraintes et les vérifications indispensables à un travail professionnel.

Pour les équipes .NET confrontées à des applications importantes, à des projets de modernisation ou à une dette technique difficile à maîtriser, NDepend 2027 mérite clairement le détour.

Une version que je vous invite à découvrir !

Liens utiles

Mises à jour de sécurité hors bande d'octobre 2026 pour .NET

odahan@e-naxos.com — lun., 2 nov. 2026 17:01:00 +0000

Quand la compression s'invite dans la danse .... En tant que développeur ou lead .NET, on a tous cette petite goutte de sueur quand une alerte de sécurité « hors bande » tombe en dehors du cycle mensuel habituel. Fin octobre 2026, Microsoft a dû dégainer de toute urgence un patch critique pour le runtime .NET.

Pourquoi ? Parce que deux failles viennent d'être corrigées, et elles touchent des composants qu'on utilise tous les jours sans y prêter attention : le décodeur Brotli et le traitement des paquets compressés.

Derrière ces termes un peu austères, c'est toute notre chaîne de traitement des données qui est sous surveillance. Je te propose qu'on décortique ensemble ce que ça implique pour nos architectures en production.

Ce que Microsoft nous dit (et ne nous dit pas)

Le 25 octobre 2026, l'équipe .NET a publié une alerte pour annoncer ces correctifs d'urgence.

Faisons un point honnête : la source officielle reste extrêmement avare en détails. Pas de CVE flamboyante, pas de score CVSS précis, ni d'exemples de code exploitables fournis par Microsoft. C'est du classique pour une alerte de ce type : on colmate l'incendie avant de donner trop de grain à moudre aux attaquants.

Ce qu'on sait de source sûre, c'est que le patch vise deux cibles bien précises :

Le décodeur Brotli, largement utilisé pour optimiser les performances web et la taille des payloads.
Une faille liée à la propriété des paquets compressés dans le runtime.

Plongée technique : pourquoi la compression devient une cible de choix

Si tu regardes l'évolution des vecteurs d'attaque récents, tu remarqueras qu'on s'attaque de plus en plus aux frontières de nos applications — là où les données externes (non fiables) entrent en contact direct avec notre code managé.

1. Le décodeur Brotli sous tension

Brotli est un super algo développé par Google, intégré nativement dans .NET pour compresser nos flux web. Mais sa complexité algorithmique et sa manipulation intensive de la mémoire en font une cible historique pour des bugs bas niveau : gestion de tampons, dépassements de mémoire, ou corruption d'état. Si un attaquant réussit à façonner un flux Brotli malicieux, il peut potentiellement provoquer un déni de service (DoS) ou, pire, une exécution de code arbitraire au cœur de ton serveur web.

2. Les paquets compressés et leurs métadonnées

La seconde vulnérabilité touche la « propriété » des paquets compressés. Même si le libellé est flou, on devine un problème dans la manière dont .NET analyse les métadonnées ou les en-têtes de ces flux. Si ton application traite des fichiers uploadés par des utilisateurs, décompresse des archives ou lit des flux réseau non sécurisés, elle se trouve directement en première ligne.

Comment réagir concrètement dans ta DSI / ton équipe ?

Plutôt que de paniquer ou de pousser le patch à l'aveugle, voici la checklist pragmatique que j'applique dans ces moments-là :

1.Audite rapidement ton parc applicatif .NET :Temps estimé : 30 min.

Identifie toutes les applications en production qui tournent sur les versions de .NET ciblées par le patch et qui manipulent des flux compressés ou des uploads massifs.

Verification: Tu obtiens une liste claire des services exposés sur le web qui utilisent Brotli.

2.Vérifie tes dépendances tierces :Attention aux bibliothèques tierces.

N'oublie pas que tes packages NuGet ou tes libs open-source embarquent parfois leurs propres wrappers ou logiques de compression. Fais un point sur ta supply chain logicielle.

Verification: Aucun package obsolète ne traîne dans tes projets critiques.

3.Pousse le patch en staging et teste :Étape critique.

Applique la mise à jour du runtime sur ton environnement de pré-production. Même si Microsoft garantit la rétrocompatibilité, teste tes endpoints soumis à de fortes charges de compression.

Verification: Les tests d'intégration et de non-régression passent haut la main sans fuite mémoire anormale.

4.Déploie en production de manière progressive :Zero downtime.

Planifie le déploiement sur tes clusters de production en mode progressif (canary ou rolling update) pour surveiller de près les métriques de CPU et de mémoire.

Verification: Les graphes de performance restent stables après le basculement.

Ce qu'on doit en retenir

Ces correctifs hors bande d'octobre 2026 nous rappellent une réalité brutale : la performance (comme la compression) a un coût en termes de surface d'attaque.

Pour nous, développeurs, la bonne réponse ne se résume pas à cliquer machinalement sur « Mettre à jour ». C'est l'occasion de garder un œil critique sur nos dépendances, d'automatiser notre veille de sécurité, et de garder nos runtimes à jour sans attendre le patch mensuel de complaisance.

Stay Tuned!

Azure Document Intelligence ou Content Understanding ?

odahan@e-naxos.com — ven., 30 oct. 2026 12:30:00 +0000

Que choisir pour vos documents ? Une facture arrive avec ses lignes d'achat, un contrat précise les conditions de paiement, puis un courriel vient modifier une échéance. Pour automatiser ce dossier, il faut récupérer les montants et les dates, mais aussi retrouver la clause qui explique leur portée. Le choix du service Azure commence là.

Microsoft propose Azure Document Intelligence et Azure Content Understanding, avec des capacités qui se recouvrent. Tous deux savent lire du texte, analyser une mise en page et extraire des champs, avec une différence qui se voit surtout dans la façon de définir l'information attendue et de la retrouver dans le document. Le guide publié par Microsoft le 7 octobre 2026 invite à choisir selon les documents réellement traités et les résultats attendus.

Pour alimenter un ERP à partir de factures, Document Intelligence reste un bon candidat lorsque son modèle préconstruit couvre les champs nécessaires et fonctionne sur les formats reçus. Une facture fournisseur peut changer de présentation sans imposer un changement de service. Il faut tester cette variation.

Document Intelligence s'appuie sur des modèles spécialisés qui exploitent les relations visuelles entre les éléments du document, notamment les libellés, les valeurs et les lignes de tableau. Pour des besoins propres à l'entreprise, Microsoft propose aussi des modèles personnalisés entraînés sur des exemples annotés, avec un modèle template pour les présentations stables et un modèle neural qui accepte des structures plus variables. La personnalisation passe donc par un modèle dédié. Parler d'un simple fine-tuning des modèles préconstruits entretient une confusion sur le travail à prévoir. La documentation des modèles personnalisés détaille ces approches.

Prenons maintenant un contrat dans lequel une date de fin se déduit d'une date de début et d'une durée. Content Understanding permet de définir les champs attendus dans un schéma et de mobiliser des modèles génératifs pour les extraire ou les produire à partir du contenu. L'information peut être dispersée entre plusieurs passages. Un analyseur personnalisé peut démarrer sans jeu d'entraînement annoté, puis être amélioré avec des exemples. Microsoft recommande cette piste pour les extractions personnalisées et les documents peu structurés.

La sortie peut rester très opérationnelle. Des données structurées issues de Content Understanding peuvent alimenter une base SQL ou un ERP, tout comme celles de Document Intelligence. La destination finale suffit donc rarement à départager les deux services. Pour un chatbot, la préparation des documents, leur indexation et la recherche des passages utiles restent des étapes à concevoir.

Les tableaux méritent aussi un examen moins expéditif. Content Understanding possède ses propres analyseurs OCR et Layout. Ses analyseurs prebuilt-read et prebuilt-layout utilisent des modèles spécialisés, sans nécessiter de modèle de langage ni de modèle d'embedding. Un tableau complexe justifie un essai comparatif sur ses cellules fusionnées, ses en-têtes et ses ruptures de page. La documentation des analyseurs préconstruits décrit leurs capacités, y compris la préparation de contenu pour la recherche.

Pour les nouveaux traitements cloud limités à l'OCR et à l'analyse de mise en page, Microsoft recommande désormais de commencer l'évaluation avec les analyseurs Content Understanding. Une application Document Intelligence qui répond déjà aux exigences de production peut rester en place. Les contraintes de déploiement, les formats acceptés ou une dépendance au détail de sa réponse peuvent aussi justifier ce choix. Ces nuances figurent dans le guide comparatif Microsoft.

Content Understanding prend davantage d'intérêt lorsqu'un dossier rassemble des PDF et d'autres médias, par exemple une déclaration de sinistre accompagnée de photos et d'un enregistrement d'appel. Il propose des analyseurs pour les documents, les images, l'audio et la vidéo. Pour les usages de recherche et de RAG, ses sorties peuvent comprendre du Markdown structuré et du contenu découpé pour l'indexation. Le moteur de recherche reste nécessaire. Ces fonctions préparent les données qu'il exploitera. Présentation de Content Understanding.

Le statut des fonctionnalités compte. La documentation recommande l'API 2025-11-01, disponible en version stable, pour la production. L'API 2026-06-01-preview permet d'évaluer les nouveautés, dont le mode agentique destiné aux analyses qui demandent plusieurs étapes de raisonnement. Ce mode reste en préversion. Il faut en tenir compte avant de lui confier un traitement critique. Fonctionnalités par version d'API.

Une exigence d'exécution locale peut trancher plus vite que la comparaison des modèles. Document Intelligence propose des conteneurs pour certaines capacités, avec une disponibilité qui dépend du modèle et de la version. Les conteneurs connectés transmettent des informations d'usage à Azure pour la facturation. L'exécution déconnectée demande un accès approuvé et un plan d'engagement. Le périmètre doit être vérifié. Microsoft précise ces conditions dans sa documentation sur les conteneurs déconnectés.

Pour un traitement cloud, l'examen doit porter sur les régions utilisées et les modèles déployés, ainsi que sur les accès, la conservation des fichiers et les traces conservées par l'application. Dans un dossier contenant des pièces d'identité, ces choix font partie de l'architecture dès le prototype.

Pour départager les services, je commencerais par un lot de documents représentatif de la production, avec les scans dégradés et les variantes qui posent déjà problème aux opérateurs. Les cent derniers documents reçus peuvent fournir un point de départ. L'échantillon doit aussi couvrir les cas rares qui bloquent le processus.

Sur une facture, une extraction utile retrouve les bons montants et permet de vérifier leur cohérence avant l'enregistrement comptable. Sur un contrat, il faut pouvoir contrôler le passage qui justifie une obligation ou une date calculée. Les scores de confiance et les références aux sources facilitent cette vérification, sans garantir à eux seuls que la valeur est correcte. Microsoft décrit ces mécanismes de confiance et de traçabilité.

Je mesurerais le taux de documents acceptés sans retouche, les erreurs sur les champs sensibles et le temps consacré aux exceptions. Le délai de traitement et le coût par document doivent être mesurés avec le même lot et les mêmes règles de validation. Une promesse de volumes massifs traités en quelques secondes ne remplace pas cet essai. Les reprises manuelles comptent aussi.

Le traitement pourrait alors suivre ce chemin, avec un routage défini à partir des résultats du prototype :

Une équipe .NET dispose des bibliothèques Azure.AI.DocumentIntelligence et Azure.AI.ContentUnderstanding pour intégrer les services. Je garderais les règles métier de validation dans une couche distincte des clients Azure, avec un résultat commun contenant les valeurs, leurs sources et les informations de confiance disponibles. Cette séparation facilite le routage par type de document.

Une architecture combinant les deux services peut avoir du sens si les essais montrent un bénéfice sur une catégorie précise. Chaque appel supplémentaire ajoute toutefois du coût et un résultat à réconcilier. Avant de construire cette chaîne, je comparerais les sorties obtenues séparément sur les mêmes factures, notamment celles que l'équipe comptable doit encore reprendre à la main.

Tout cela évolue très vite, tout le monde s'empresse d'offrir des services IA dans le Cloud prenant en charge des spécificités métiers, afin de créer une clientèle captive. N'oublions donc pas que l'IA locale permet entre autres choses d'éviter ce piège financier. Ce nouveau produit Microsoft "clé en main" est séduisant, mais son coût sur le long terme, le coût de la dépendance, celui de l'envoi de vos données sensibles à l'extérieur de votre société, êtes vous capable d'évaluer correctement toutes les conséquences ?

Stay Tuned!

L'automatisation de navigateurs sur Microsoft Foundry passe en GA

odahan@e-naxos.com — lun., 26 oct. 2026 12:30:00 +0000

Si vous me lisez régulièrement, vous savez à quel point l'automatisation des tâches web est devenue le nerf de la guerre. Entre la réduction des opérations répétitives, la recherche d'une meilleure fiabilité sur des interfaces web parfois capricieuses et l'essor des architectures agentiques, le sujet est sur toutes les lèvres.

Récemment (le 19 octobre 2026), le blog Microsoft Foundry a officialisé le passage en disponibilité générale (General Availability - GA) de son outil d'automatisation de navigateurs.

C'est une excellente nouvelle sur le papier pour industrialiser nos agents web, mais restons pragmatiques : si cette annonce marque une étape concrète, elle ne nous dispense pas d'une analyse critique du produit, de ses limites et de ses conditions de déploiement en production.

Ce que Microsoft annonce officiellement

Restons aux faits. L'article publié par l'équipe Microsoft Foundry annonce la GA de son outil d'automatisation de navigateurs, conçu pour vous aider à bâtir des agents capables d'interagir avec des sites web publics comme privés.

Sur le plan fonctionnel, Microsoft met en avant 4 piliers majeurs :

Navigateurs gérés (Managed Browsers)
Intégration native à la boîte à outils Foundry
Live View (visualisation en direct)
Contrôle humain dans la boucle (Human-in-the-loop)

Mon point d'attention : À ce stade, la communication officielle reste très concise. Microsoft ne fournit pas encore de détails sur les versions sous-jacentes, la grille tarifaire, les limites de performance ou les critères de comparaison (benchmarks). Tout ce qui suit repose donc sur mon analyse d'architecte et mon retour d'expérience terrain.

Décryptage technique : De quoi parle-t-on vraiment ?

1. Des navigateurs gérés pour alléger l'Ops

Gérer le cycle de vie d'un navigateur en automatisation est un enfer opérationnel : provisioning, configuration des sessions, gestion des cookies, certificats TLS, nettoyage des instances... L'approche "gérée" laisse entendre que Microsoft prend en charge cette complexité infrastructurelle.

La question à vous poser avant de vous lancer : S'agit-il d'un exécution 100 % cloud, hybride ou autorisant du on-premises ? La réponse sera décisive pour vos contraintes réglementaires.

2. Intégration native dans Microsoft Foundry

Si votre pile technique repose déjà sur l'écosystème Microsoft (notamment les équipes .NET ou Azure), c'est un point très positif. Pas besoin de bricoler des connecteurs tiers pour orchestrer vos agents. L'outil s'intègre directement dans la chaîne de build et d'exécution Foundry.

3. Live View : Le debug enfin simplifié

Si vous avez déjà essayé de débugger un script de scraping ou un agent headless à l'aveugle, vous savez à quel point c'est frustrant. L'arrivée du Live View permet d'observer l'état du navigateur, le rendu DOM et les actions en temps réel. C'est un gain de temps précieux lors de la phase de dev et pour surveiller le comportement des agents en production.

4. Le contrôle humain (Human-in-the-Loop)

C'est pour moi le composant le plus critique. L'automatisation totale sur des processus métier sensibles (mouvements financiers, modification de données RH) est souvent une illusion risquée. Avoir un mécanisme natif permettant à un utilisateur d'approuver, corriger ou stopper une action en direct apporte un niveau de sécurité indispensable pour nos métiers.

Ce que j'aime... et ce qui m'inquiète

Les vrais points forts :

Sites publics ET privés : Pouvoir automatiser des tâches sur des applications internes (intranet, ERP web) autant que sur des portails externes ouvre d'immenses opportunités d'automatisation UI.
Supervision facilitée : Le couple Live View + Contrôle humain répond directement aux problématiques de gouvernance.

Les zones d'ombre à garder en tête :

La fragilité intrinsèque des interfaces web : Un simple changement de classe CSS ou d'ID dans une application web peut casser un agent. Microsoft ne détaille pas encore de mécanisme d'auto-réparation (self-healing) par IA pour gérer ces changements d'IHM.
Sécurité & Conformité : Autoriser un agent autonome à naviguer sur vos portails privés exige une gestion d'identités et d'accès ultra-stricte (IAM, coffre-fort de secrets). Ne négligez pas cet aspect sous prétexte que le service est estampillé "GA".
Le risque de sur-automatisation : Ce n'est pas parce qu'on peut automatiser une tâche via le navigateur qu'il faut le faire. Si une API existe, privilégiez toujours l'API ! L'automatisation web doit rester une solution pour les systèmes légacy ou dépourvus d'interfaces de programmation.

Mes 8 recommandations pour vos projets (.NET / DSI)

Si vous envisagez de tester ou de déployer cet outil dans vos équipes, voici ma feuille de route :

Filtrez vos cas d'usage : Commencez par des tâches répétitives à faible risque et haute fréquence. Gardez les processus critiques pour une phase de maturité ultérieure.
Définissez le niveau d'intervention humaine : Déterminez clairement où le "Human-in-the-loop" s'impose (validation à l'étape, validation finale ou audit a posteriori).
Mettez en place un environnement de bac à sable (Sandbox) : Ne faites jamais tourner vos agents de test directement sur vos environnements de production web.
Prévoyez la maintenance : La maintenance d'un agent web n'est pas nulle. Incorporez une charge récurrente pour mettre à jour les scripts au fil des évolutions des sites ciblés.
Consolidez le monitoring : Ne vous reposez pas uniquement sur le Live View. Connectez vos agents à vos outils de métriques et d'alerting existants.
Sécurisez la gestion des identifiants : Assurez-vous que l'agent consomme des secrets sécurisés et respecte le principe du moindre privilège.
Documentez les scénarios d'échec : Que fait l'agent si le site web cible est inaccessible ou en maintenance ? Prévoyez des replis gracieux (fallback).
Formez les équipes opérationnelles : La technologie n'est qu'une partie du sujet. Les opérateurs métier doivent savoir comment reprendre la main si l'agent sollicite une validation.

En conclusion

Le passage en GA de l'outil d'automatisation de navigateurs dans Microsoft Foundry est un indicateur clair : l'automatisation basée sur des agents quitte les laboratoires pour s'implanter dans la réalité industrielle.

L'outil offre une base technique prometteuse, mais le succès dépendra à 80 % de votre méthode : sélection des bons cas d'usage, rigueur dans la sécurité et intégration harmonieuse de l'humain dans la boucle.

Comme toujours le vrai point fort (ou faible) d'un SI, ce sont les humains et pas les outils. A vous de bien vous servir de cette nouvelle possibilité !

Stay Tuned!

Bien utiliser EF Core : requêtes, performances et production

odahan@e-naxos.com — ven., 23 oct. 2026 13:30:00 +0000

Le code qui fonctionne n'est que le point de départ.

Série — Entity Framework : remettre les compteurs à zéro
Partie 4 sur 4. Le projet précédent sait créer, lire et modifier une base SQLite. Il faut maintenant rendre ses coûts visibles et ses comportements explicites.

EF Core n'est pas lent ; une requête peut l'être

La phrase « EF Core est lent » ne décrit rien de mesurable. Elle peut désigner :

une requête qui transfère trop de colonnes ;
l'absence d'un index ;
un problème N+1 ;
un graphe chargé avec plusieurs collections ;
une pagination profonde avec OFFSET ;
un contexte conservant des milliers d'entités suivies ;
des centaines d'allers-retours ;
un verrouillage long ;
une traduction moins adaptée que le SQL spécifique au moteur.

Le travail sérieux commence en identifiant le SQL, le plan d'exécution, la cardinalité, le nombre d'allers-retours et la durée. L'ORM ne dispense pas de cette analyse ; il ajoute une étape de traduction qu'il faut connaître.

1. Garder le DbContext court et séquentiel

Microsoft décrit DbContext comme une unité de travail normalement courte et précise qu'il n'est pas thread-safe [1].

Un usage correct :

await using var db = dbContextFactory.CreateDbContext();

var order = await db.Orders
    .SingleAsync(order => order.Id == orderId, cancellationToken);

order.Status = OrderStatus.Shipped;

await db.SaveChangesAsync(cancellationToken);

Un usage incorrect :

// À ne pas faire : deux opérations concurrentes sur le même contexte.
var customersTask = db.Customers.ToListAsync(cancellationToken);
var ordersTask = db.Orders.ToListAsync(cancellationToken);

await Task.WhenAll(customersTask, ordersTask);

Si ces requêtes doivent réellement être parallèles, elles nécessitent des contextes distincts. Mais paralléliser deux accès à la même base n'est pas automatiquement plus rapide : la contention, le pool de connexions et le coût côté serveur comptent.

Un contexte ne doit pas devenir :

un singleton ;
un cache général ;
un champ statique ;
un objet partagé entre traitements parallèles ;
une session utilisateur de plusieurs heures.

2. Projeter avant de penser `Include`

Pour produire une réponse d'API, un écran ou un export, l'application connaît généralement la forme attendue.

public sealed record OrderSummary(
    int Id,
    DateTime CreatedAtUtc,
    string CustomerName,
    int LineCount,
    long TotalCents);

var orders = await db.Orders
    .Where(order => order.Status == OrderStatus.Confirmed)
    .OrderByDescending(order => order.CreatedAtUtc)
    .ThenByDescending(order => order.Id)
    .Select(order => new OrderSummary(
        order.Id,
        order.CreatedAtUtc,
        order.Customer.Name,
        order.Lines.Count,
        order.Lines.Sum(
            line => line.UnitPriceCents * line.Quantity)))
    .Take(50)
    .ToListAsync(cancellationToken);

Cette requête :

sélectionne uniquement les données utiles ;
calcule en base ;
ne matérialise pas un graphe d'entités ;
évite le tracking d'entités puisqu'elle produit des valeurs et un DTO.

La documentation Microsoft recommande de projeter uniquement les propriétés nécessaires [2]. Include doit être choisi lorsqu'un véritable graphe d'entités est nécessaire, pas comme réflexe de chargement.

3. Utiliser le tracking intentionnellement

Une requête d'entités est suivie par défaut :

var customer = await db.Customers
    .SingleAsync(customer => customer.Id == customerId);

customer.Email = newEmail;
await db.SaveChangesAsync();

Pour une lecture seule d'entités :

var customers = await db.Customers
    .AsNoTracking()
    .OrderBy(customer => customer.Name)
    .ToListAsync();

La règle pratique est simple :

modification dans la même unité de travail : tracking ;
lecture seule d'entités : AsNoTracking ;
lecture destinée à une présentation : projection vers une forme dédiée.

Ajouter AsNoTracking à toutes les requêtes par automatisme n'est pas une compréhension. Dans une requête qui retourne plusieurs occurrences de la même entité, le tracking peut économiser des instances grâce à la résolution d'identité. AsNoTrackingWithIdentityResolution constitue un compromis lorsque cette propriété est utile sans suivi ultérieur [3].

4. Le lazy loading rend les allers-retours invisibles

Avec le lazy loading, ce code apparemment innocent peut exécuter une requête pour les commandes, puis une autre pour les lignes de chaque commande :

var orders = await db.Orders.ToListAsync();

foreach (var order in orders)
{
    Console.WriteLine($"Commande {order.Id}: {order.Lines.Count} lignes");
}

Pour N commandes, on obtient potentiellement 1 + N requêtes. La documentation Microsoft avertit explicitement que le lazy loading est particulièrement susceptible de provoquer ce problème [2][4].

Une projection explicite rend le coût visible :

var orders = await db.Orders
    .Select(order => new
    {
        order.Id,
        LineCount = order.Lines.Count
    })
    .ToListAsync();

Le lazy loading n'est pas intrinsèquement défectueux. Il est dangereux lorsque l'on ne maîtrise pas précisément le chemin d'accès aux propriétés et le nombre d'allers-retours. Dans une API serveur, je recommande de le désactiver par défaut.

5. `Include`, explosion cartésienne et requêtes fractionnées

Charger plusieurs collections sœurs avec une requête unique peut multiplier les lignes du résultat SQL. Dix lignes de commande et six paiements ne produisent pas seize lignes, mais potentiellement soixante combinaisons avant reconstruction du graphe.

var customers = await db.Customers
    .Include(customer => customer.Orders)
        .ThenInclude(order => order.Lines)
    .ToListAsync();

Selon le graphe, AsSplitQuery() peut remplacer une grande jointure par plusieurs requêtes :

var customers = await db.Customers
    .Include(customer => customer.Orders)
        .ThenInclude(order => order.Lines)
    .AsSplitQuery()
    .ToListAsync();

Il n'existe pas de gagnant universel :

requête unique : moins d'allers-retours, mais duplication possible ;
requêtes fractionnées : moins d'explosion cartésienne, mais plusieurs commandes et des considérations de cohérence entre lectures.

La documentation officielle demande explicitement de choisir selon le scénario [5]. Mesurez le volume et observez le SQL.

Figure 9 — Projection, requête unique avec Include et requêtes fractionnées répondent à des besoins distincts.

6. Paginer avec un ordre totalement déterministe

La pagination classique est simple :

var page = await db.Orders
    .OrderByDescending(order => order.CreatedAtUtc)
    .ThenByDescending(order => order.Id)
    .Skip((pageNumber - 1) * pageSize)
    .Take(pageSize)
    .Select(order => new { order.Id, order.CreatedAtUtc })
    .ToListAsync();

L'ordre doit être totalement unique. Trier uniquement par date permet à deux lignes ayant la même date de changer de position entre deux requêtes [6].

Pour naviguer vers la page suivante à grande profondeur, la pagination par curseur évite de faire parcourir au moteur toutes les lignes précédentes :

var page = await db.Orders
    .Where(order =>
        order.CreatedAtUtc < cursorDate
        || (order.CreatedAtUtc == cursorDate && order.Id < cursorId))
    .OrderByDescending(order => order.CreatedAtUtc)
    .ThenByDescending(order => order.Id)
    .Take(pageSize)
    .Select(order => new { order.Id, order.CreatedAtUtc })
    .ToListAsync();

La pagination par curseur ne permet pas de sauter naturellement à la page 427. Elle est adaptée aux navigations précédent/suivant et aux flux continus.

7. Modifier en mémoire ou directement en base

Le change tracker convient à une règle métier portant sur une entité :

var order = await db.Orders
    .SingleAsync(order => order.Id == orderId);

if (order.Status != OrderStatus.Confirmed)
{
    throw new InvalidOperationException(
        "Seule une commande confirmée peut être expédiée.");
}

order.Status = OrderStatus.Shipped;
await db.SaveChangesAsync();

Pour archiver un ensemble, il serait absurde de tout charger :

var affectedRows = await db.Orders
    .Where(order =>
        order.Status == OrderStatus.Cancelled
        && order.CreatedAtUtc < limitUtc)
    .ExecuteDeleteAsync();

Ou pour modifier plusieurs lignes :

var affectedRows = await db.Orders
    .Where(order => order.Status == OrderStatus.Draft)
    .ExecuteUpdateAsync(setters => setters
        .SetProperty(
            order => order.Status,
            OrderStatus.Cancelled));

ExecuteUpdate et ExecuteDelete :

exécutent immédiatement leur ordre ;
ne passent pas par SaveChanges ;
ignorent les entités déjà suivies ;
ne regroupent pas automatiquement plusieurs appels dans une seule transaction.

Mélanger une mise à jour ensembliste et des entités suivies dans le même contexte peut laisser la mémoire en désaccord avec la base [7]. Il faut isoler l'opération ou recharger explicitement.

8. Traiter la concurrence comme un cas normal

Deux utilisateurs lisent la même commande. Le premier la modifie. Le second enregistre ensuite une version construite à partir d'un état ancien. Sans contrôle, la dernière écriture peut écraser la précédente.

Dans notre modèle SQLite, Version est un Guid configuré comme jeton de concurrence :

builder.Property(order => order.Version)
    .IsConcurrencyToken();

EF Core ajoute sa valeur d'origine à la clause WHERE de l'UPDATE. Si aucune ligne ne correspond, SaveChangesAsync lève DbUpdateConcurrencyException.

try
{
    order.Status = OrderStatus.Shipped;
    await db.SaveChangesAsync();
}
catch (DbUpdateConcurrencyException exception)
{
    foreach (var entry in exception.Entries)
    {
        await entry.ReloadAsync();
    }

    throw new InvalidOperationException(
        "La commande a été modifiée par un autre traitement.",
        exception);
}

Recharger puis réessayer automatiquement n'est pas toujours correct. Il faut décider entre :

abandonner et informer l'utilisateur ;
fusionner certaines propriétés ;
appliquer la valeur de la base ;
réévaluer la règle métier puis retenter.

SQL Server peut générer un rowversion. SQLite ne prend pas en charge les jetons de concurrence générés par la base [8]. La stratégie dépend donc du fournisseur.

9. Comprendre la transaction implicite avant d'en ajouter une

Par défaut, si le fournisseur prend en charge les transactions, un appel à SaveChanges est atomique [9]. Il est inutile d'ajouter systématiquement une transaction explicite autour d'un seul appel.

Une transaction explicite devient nécessaire lorsque plusieurs phases doivent réussir ensemble :

await using var transaction = await db.Database.BeginTransactionAsync();

try
{
    order.Status = OrderStatus.Shipped;
    await db.SaveChangesAsync();

    await db.Products
        .Where(product => product.Id == productId)
        .ExecuteUpdateAsync(setters => setters
            .SetProperty(
                product => product.UnitPriceCents,
                product => product.UnitPriceCents + 100));

    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

Une transaction doit être courte. Ne la conservez pas pendant que l'utilisateur remplit un écran ou qu'un service distant répond.

10. Descendre en SQL sans quitter EF Core

Une requête spécifique au moteur peut être plus claire en SQL :

var minimumDate = DateTime.UtcNow.AddDays(-30);

var recentOrders = await db.Orders
    .FromSql($"""
        SELECT Id, CreatedAtUtc, Status, CustomerId, Version
        FROM Orders
        WHERE CreatedAtUtc >= {minimumDate}
        """)
    .AsNoTracking()
    .ToListAsync();

FromSql et FromSqlInterpolated paramètrent les valeurs interpolées. FromSqlRaw doit être réservé aux cas où la structure SQL est réellement dynamique et contrôlée ; concaténer une entrée utilisateur y créerait une injection SQL [10].

Pour un ordre ne retournant pas d'entités :

var affectedRows = await db.Database.ExecuteSqlAsync($"""
    UPDATE Products
    SET UnitPriceCents = UnitPriceCents + {increaseCents}
    WHERE Id = {productId}
    """);

L'utilisation de SQL brut n'est pas un aveu d'échec. C'est une échappatoire officielle de l'abstraction.

11. Le Repository générique masque souvent l'outil utile

Une abstraction de ce type paraît propre :

public interface IRepository<TEntity>
    where TEntity : class
{
    Task<List<TEntity>> GetAllAsync();
    Task<TEntity?> GetByIdAsync(int id);
    void Add(TEntity entity);
    void Remove(TEntity entity);
}

Elle duplique pourtant DbSet<TEntity> et réduit l'expressivité des requêtes. Dès qu'un écran exige une projection, un agrégat, un filtre ou un Include, trois issues apparaissent :

ajouter une méthode spécifique pour chaque besoin ;
créer un langage de spécifications reproduisant LINQ ;
exposer IQueryable, ce qui annule l'isolation recherchée.

Un repository métier peut être utile s'il expose une intention réelle :

public interface IOrderRepository
{
    Task<Order?> FindConfirmedForShippingAsync(
        int orderId,
        CancellationToken cancellationToken);
}

Mais poser mécaniquement un CRUD générique au-dessus d'EF Core ajoute rarement une valeur architecturale. DbContext est déjà une unité de travail et DbSet fournit déjà une abstraction d'ensemble.

12. Tester la requête contre le moteur qui l'exécutera

SQLite est excellent pour une démonstration et utile pour certains tests rapides. Il n'est pas un double fidèle de SQL Server, PostgreSQL ou Oracle.

Les différences peuvent concerner :

la casse des comparaisons ;
les fonctions disponibles ;
les types ;
les requêtes SQL brutes ;
les migrations ;
les transactions ;
la traduction d'expressions spécifiques.

Microsoft déconseille également le fournisseur InMemory comme substitut général d'une base relationnelle : il prend en charge moins de requêtes, ne gère pas les transactions et n'exécute pas de SQL brut [11].

Une stratégie raisonnable contient plusieurs niveaux :

tests unitaires du domaine sans EF Core lorsque c'est possible ;
tests rapides de certains composants avec SQLite si leurs hypothèses sont compatibles ;
tests d'intégration contre le véritable moteur pour les requêtes, migrations et comportements critiques.

Les conteneurs rendent aujourd'hui ce dernier niveau beaucoup moins coûteux qu'autrefois.

13. Déployer les migrations comme un artefact contrôlé

En développement :

dotnet ef migrations add AddShippingDate
dotnet ef database update

En production, exécuter aveuglément dotnet ef database update depuis une machine ou appeler MigrateAsync() au démarrage n'est pas une stratégie universelle.

Microsoft présente plusieurs options [12] :

script SQL relu et exécuté par le processus de déploiement ;
script idempotent lorsque l'état initial varie ;
bundle de migrations construit en CI ;
migration au démarrage pour les systèmes simples acceptant ce compromis.

Pour générer un script idempotent :

dotnet ef migrations script --idempotent --output migrations.sql

Pour créer un bundle :

dotnet ef migrations bundle --output artifacts/efbundle

La documentation actuelle précise que la migration au démarrage bénéficie d'un verrou global depuis EF Core 9, mais qu'une étape séparée reste préférable lorsqu'il faut revue SQL, privilèges minimaux, coordination du déploiement ou haute disponibilité [12].

Une migration de production doit être traitée comme du code sensible :

relue ;
testée sur une copie réaliste ;
chronométrée ;
accompagnée d'une stratégie de sauvegarde ou de retour ;
compatible avec le déploiement progressif de l'application.

14. EF Core, Dapper ou SQL : choisir par chemin d'exécution

Besoin dominant	Choix généralement cohérent
Modèle métier, relations, changements sur plusieurs entités	EF Core
CRUD et projections ordinaires	EF Core
Lecture SQL déjà conçue et stable	Dapper ou `SqlQuery`/`FromSql`
Reporting très spécifique au moteur	SQL, vues, Dapper ou outil dédié
Mise à jour ensembliste simple	`ExecuteUpdate` / `ExecuteDelete`
Chargement massif spécialisé	API du moteur ou bibliothèque dédiée
Quelques requêtes dans un petit service	ADO.NET ou Dapper peuvent suffire
Application mêlant domaine et reporting	EF Core et SQL explicite peuvent coexister

Le choix peut varier au sein d'une même application. Imposer un outil unique pour préserver une pureté théorique crée parfois plus de complexité que l'emploi raisonné de deux approches.

Figure 10 — Une requête n'est terminée que lorsque son SQL, son volume et son comportement sur le véritable moteur ont été vérifiés.

Une checklist de revue

Avant de valider un accès EF Core, posez les questions suivantes :

Requête

La forme retournée correspond-elle exactement au besoin ?
Le nombre de lignes est-il borné ?
L'ordre est-il déterministe ?
Les relations sont-elles chargées explicitement ?
Combien d'allers-retours sont exécutés ?
Le SQL et le plan ont-ils été inspectés ?

Écriture

L'unité de travail est-elle courte ?
SaveChanges suffit-il comme frontière transactionnelle ?
Une opération ensembliste éviterait-elle la matérialisation ?
Un conflit de concurrence est-il possible ?
Les contraintes importantes existent-elles aussi dans la base ?

Fournisseur

La requête a-t-elle été testée sur le moteur de production ?
Les types et conversions sont-ils adaptés ?
Les fonctions utilisées sont-elles réellement prises en charge ?
Les packages du fournisseur sont-ils compatibles avec la version d'EF Core ?

Déploiement

La migration a-t-elle été relue ?
Le SQL a-t-il été testé sur un volume réaliste ?
L'identité applicative possède-t-elle uniquement les droits nécessaires ?
Le déploiement de code est-il compatible avec l'ancien et le nouveau schéma pendant la transition ?

Conclusion générale : remettre les compteurs à zéro ne signifie pas tout oublier

Entity Framework a changé parce que .NET, les architectures applicatives et les exigences d'exploitation ont changé. Bon, c'est la version polie. En réalité il y a eu pas mal de maladresses, d'essais/échecs qui auraient du rester internes chez Microsoft au lieu d'être poussés à l'extérieur, plongeant des tas de développeurs dans l'incompréhension, ce fut mal géré. Ainsi, le modèle conceptuel initial a cédé la place à un outil davantage centré sur le code. EF Core a commencé comme une réécriture incomplète, puis a reconstruit un ensemble cohérent autour de LINQ, du suivi, des migrations et de fournisseurs modulaires.

Ce parcours ne rend pas les connaissances relationnelles obsolètes. Il les rend plus importantes. Une expression LINQ n'est pas une requête abstraite suspendue au-dessus de la réalité : elle doit devenir le SQL d'un moteur précis. Une migration n'est pas une intention : elle devient une modification réelle de données et de structures. Un DbContext n'est pas un cache : c'est une unité de travail. EF Core ne permet donc pas de faire l'économie d'une bonne connaissance de SQL et des bases de données relationnelles, effacer SQL, ce n'est pas son but. Tout simplement.

EF Core est aujourd'hui simple à démarrer et suffisamment observable pour rester sous contrôle. Il convient très bien à une large classe d'applications métier. Il ne remplace ni Dapper, ni SQL explicite, ni les outils spécialisés lorsque leurs compromis sont meilleurs.

La conclusion la plus saine n'est donc pas « utilisez EF Core partout ». Elle est plus exigeante :

Évaluez EF Core à partir de ce qu'il est aujourd'hui, puis vérifiez toujours ce qu'il demande réellement à votre base.

J'espère que cette série d'article sur Entity Framework vous aura permis de faire enfin le point sur ce monstre, gentil, mais aux mille visages. EF 10 est exploitable, ce n'est plus une usine à gaz et tout ce que vous avez pu apprendre au fil des versions et des ans, est, presque totalement, devenu caduque. Il est donc temps de jeter un nouveau regard sur ce framework.

Stay Tuned!

Références

Microsoft Learn, « DbContext Lifetime, Configuration, and Initialization ».
Microsoft Learn, « Efficient Querying ».
Microsoft Learn, « Tracking vs. No-Tracking Queries ».
Microsoft Learn, « Lazy Loading of Related Data ».
Microsoft Learn, « Single vs. Split Queries ».
Microsoft Learn, « Pagination ».
Microsoft Learn, « ExecuteUpdate and ExecuteDelete ».
Microsoft Learn, « Handling Concurrency Conflicts » et limites du fournisseur SQLite.
Microsoft Learn, « Using Transactions ».
Microsoft Learn, « SQL Queries ».
Microsoft Learn, « Choosing a testing strategy ».
Microsoft Learn, « Applying Migrations ».
Microsoft Learn, « Testing against your Production Database System ».

Dot.Blog

NDepend 2027 : quand l'IA s'attaque véritablement à la dette technique de nos applications .NET

De l'analyse de code à l'amélioration assistée par l'IA

Les agents IA ont besoin d'un instrument de mesure

NDepend.AI : le meilleur de deux mondes

Claude, Codex et les autres : l'intérêt d'une approche ouverte

La correction par itérations : un processus plutôt qu'un simple prompt

Une démonstration concrète sur Jellyfin

Mesurer les corrections, mais aussi leurs conséquences

Les Quality Gates : définir ce que signifie « terminé »

La couverture des tests, indispensable à une IA réellement utile

Le retour en grâce des règles et du déterminisme

Une nouvelle manière d'aborder les projets de modernisation .NET

Mon avis : NDepend prend une direction particulièrement pertinente

Conclusion : NDepend 2027, bien plus qu'une évolution cosmétique

Liens utiles

Mises à jour de sécurité hors bande d'octobre 2026 pour .NET

Ce que Microsoft nous dit (et ne nous dit pas)

Plongée technique : pourquoi la compression devient une cible de choix

1. Le décodeur Brotli sous tension

2. Les paquets compressés et leurs métadonnées

Comment réagir concrètement dans ta DSI / ton équipe ?

Ce qu'on doit en retenir

Azure Document Intelligence ou Content Understanding ?

L'automatisation de navigateurs sur Microsoft Foundry passe en GA

Ce que Microsoft annonce officiellement

Décryptage technique : De quoi parle-t-on vraiment ?

1. Des navigateurs gérés pour alléger l'Ops

2. Intégration native dans Microsoft Foundry

3. Live View : Le debug enfin simplifié

4. Le contrôle humain (Human-in-the-Loop)

Ce que j'aime... et ce qui m'inquiète

Les vrais points forts :

Les zones d'ombre à garder en tête :

Mes 8 recommandations pour vos projets (.NET / DSI)

En conclusion

Bien utiliser EF Core : requêtes, performances et production

EF Core n'est pas lent ; une requête peut l'être

1. Garder le DbContext court et séquentiel

2. Projeter avant de penser Include

3. Utiliser le tracking intentionnellement

4. Le lazy loading rend les allers-retours invisibles

5. Include, explosion cartésienne et requêtes fractionnées

6. Paginer avec un ordre totalement déterministe

7. Modifier en mémoire ou directement en base

8. Traiter la concurrence comme un cas normal

9. Comprendre la transaction implicite avant d'en ajouter une

10. Descendre en SQL sans quitter EF Core

11. Le Repository générique masque souvent l'outil utile

12. Tester la requête contre le moteur qui l'exécutera

13. Déployer les migrations comme un artefact contrôlé

14. EF Core, Dapper ou SQL : choisir par chemin d'exécution

Une checklist de revue

Requête

Écriture

Fournisseur

Déploiement

Conclusion générale : remettre les compteurs à zéro ne signifie pas tout oublier

Références

2. Projeter avant de penser `Include`

5. `Include`, explosion cartésienne et requêtes fractionnées