Dot.Blog

Pourquoi avons-nous inventé les ORM ?

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

La persistance objet avant Entity Framework, chez Microsoft et ailleurs.

Série — Entity Framework : remettre les compteurs à zéro
Partie 1 sur 4. Cet article revient sur le problème que les ORM tentent de résoudre. Il prépare l'histoire d'Entity Framework sans en faire encore le sujet principal.

Un objet n'est pas une ligne

Une classe C# et une table SQL peuvent sembler proches : des propriétés d'un côté, des colonnes de l'autre. Cette ressemblance est trompeuse.

Considérons un modèle métier élémentaire :

public sealed class Customer
{
    public int Id { get; set; }
    public required string Name { get; set; }
    public List<Order> Orders { get; set; } = [];
}

public sealed class Order
{
    public int Id { get; set; }
    public DateTime CreatedAtUtc { get; set; }
    public OrderStatus Status { get; set; }
    public List<OrderLine> Lines { get; set; } = [];
}

Dans le programme, un client référence une collection de commandes. Une commande contient des lignes. Chaque instance possède une identité et un cycle de vie. Le développeur navigue dans un graphe.

Dans la base relationnelle, les mêmes données sont distribuées entre des tables. Les relations reposent sur des clés étrangères. Retrouver le graphe nécessite des jointures ; enregistrer ses modifications nécessite de respecter un ordre, des contraintes et une transaction.

Figure 3 — L'ORM ne fait pas seulement correspondre des propriétés à des colonnes : il reconstruit et synchronise un graphe à partir d'ensembles de lignes.

Le terme classique est object-relational impedance mismatch, le décalage objet-relationnel. Il regroupe plusieurs difficultés :

l'identité d'un objet n'est pas simplement son emplacement en mémoire ;
une référence objet devient une clé étrangère ;
une collection devient une requête ;
l'héritage n'a pas un équivalent relationnel unique ;
un type valeur riche peut être réparti entre plusieurs colonnes ;
le chargement partiel d'un graphe pose la question de ce qui est présent ou absent ;
la modification d'un objet doit devenir un ensemble minimal d'ordres SQL ;
deux utilisateurs peuvent modifier la même ligne entre lecture et écriture.

La documentation de Hibernate résume l'objectif historique de l'ORM comme la suppression du code fragile et non typé afin de rendre les grands programmes plus maintenables [1]. Cette ambition est plus précise que « ne plus écrire de SQL ».

Ce que coûte réellement le mapping manuel

Le SQL explicite est robuste et prévisible. Il ne faut pas le caricaturer. Une lecture ADO.NET correctement écrite est parfaitement saine :

await using var command = connection.CreateCommand();
command.CommandText = """
    SELECT Id, Name
    FROM Customers
    WHERE Id = @id;
    """;

var idParameter = command.CreateParameter();
idParameter.ParameterName = "@id";
idParameter.Value = customerId;
command.Parameters.Add(idParameter);

await using var reader = await command.ExecuteReaderAsync();

Customer? customer = null;

if (await reader.ReadAsync())
{
    customer = new Customer
    {
        Id = reader.GetInt32(0),
        Name = reader.GetString(1)
    };
}

Ce code a plusieurs qualités : la requête est visible, les colonnes sont choisies et l'exécution ne comporte pas de mécanisme implicite. Mais le coût ne se limite pas à ces vingt lignes. Il faut encore :

reconstruire les commandes du client ;
éviter de créer plusieurs instances représentant la même ligne ;
détecter les objets nouveaux, modifiés ou supprimés ;
générer les INSERT, UPDATE et DELETE dans le bon ordre ;
convertir les valeurs et traiter les NULL ;
gérer la transaction ;
détecter les conflits de concurrence ;
maintenir le mapping après chaque évolution du schéma.

Le mapping manuel ne devient pas mauvais pour autant. Il devient coûteux lorsque ces opérations se répètent sur des dizaines d'entités et des centaines de requêtes.

Les patterns existaient avant les produits

Les ORM n'ont pas inventé toutes leurs idées. Ils industrialisent des patterns de persistance déjà identifiés.

Active Record

L'objet porte lui-même les opérations de persistance :

public sealed class Customer
{
    public int Id { get; private set; }
    public required string Name { get; set; }

    public Task SaveAsync(CancellationToken cancellationToken = default)
    {
        // La classe connaît directement son stockage.
        throw new NotImplementedException();
    }
}

Cette approche est directe et efficace pour des applications simples. Elle couple cependant le modèle métier à la persistance et devient moins confortable lorsque les transactions impliquent plusieurs types.

Data Mapper

Le mapping est confié à un composant séparé :

public interface ICustomerMapper
{
    Task<Customer?> FindAsync(
        int id,
        CancellationToken cancellationToken = default);

    Task InsertAsync(
        Customer customer,
        CancellationToken cancellationToken = default);
}

Le domaine ignore alors les détails de stockage. Les ORM complets, dont Entity Framework et Hibernate, se rapprochent généralement de cette famille.

Unit of Work

Une unité de travail mémorise les changements effectués pendant une opération métier et les synchronise avec la base au moment approprié. La documentation Microsoft reprend la définition de Martin Fowler : une unité de travail « keeps track of everything you do during a business transaction » [2]. Avec EF Core, DbContext remplit précisément ce rôle.

Identity Map

Si deux requêtes d'une même unité de travail rencontrent la ligne Customers.Id = 42, elles devraient généralement obtenir la même instance suivie. Sans cette garantie, deux représentations contradictoires du même client peuvent coexister en mémoire.

Ces patterns permettent de comprendre les services rendus par un ORM sans les attribuer à une quelconque magie.

De l'ORM complet au micro-ORM

Toutes les bibliothèques de persistance ne choisissent pas le même niveau d'automatisation.

Approche	Ce qu'elle automatise	Ce qu'elle laisse au développeur
ADO.NET	Connexion, commande, lecteur, paramètres	SQL, mapping, suivi et unité de travail
Micro-ORM	Exécution et mapping des résultats	SQL, stratégie de chargement, changements
ORM complet	Mapping, requêtes, relations, suivi, migrations	Modèle, intentions, contrôle du SQL et optimisation
Active Record	Persistance attachée au modèle	Organisation métier et requêtes spécifiques

Dapper, apparu plus tard dans l'écosystème .NET, occupe volontairement une position intermédiaire : le développeur écrit le SQL, tandis que la bibliothèque matérialise les résultats. Entity Framework prend en charge un périmètre plus large, au prix d'une abstraction plus importante.

La question pertinente n'est donc pas « ORM ou pas ORM ? », mais « quelle partie de la plomberie voulons-nous automatiser dans ce contexte ? »

Hors de Microsoft : plusieurs réponses au même problème

Les premières solutions objet-relationnelles sont antérieures à .NET. Les bases objet, les outils Smalltalk, TopLink, puis Hibernate dans l'écosystème Java ont exploré différentes manières de préserver une programmation orientée objet au-dessus d'un stockage relationnel.

Hibernate a particulièrement influencé la perception moderne des ORM : classes persistantes ordinaires, sessions, requêtes sur le modèle objet, suivi des changements et mapping configurable. NHibernate a porté cette famille d'idées vers .NET.

Il serait toutefois incorrect de raconter une progression linéaire où chaque nouvel outil remplace le précédent. Les approches ont coexisté parce qu'elles optimisent des besoins différents, alimentant encore plus la confusion dans les souvenirs :

application métier orientée domaine ;
reporting centré sur le modèle relationnel ;
traitement par lots ;
lecture à très fort volume ;
base héritée dominée par les procédures stockées ;
produit multiplateforme devant prendre en charge plusieurs moteurs.

Même la documentation Hibernate actuelle insiste sur un point souvent oublié : son objectif n'est pas de cacher SQL ou le modèle relationnel [3]. Cette observation vaut aussi pour EF Core.

Chez Microsoft : avant Entity Framework

ADO puis ADO.NET

ADO.NET fournit les primitives fondamentales : connexions, commandes, transactions, paramètres, lecteurs et adaptateurs. Son modèle est explicite et proche de la base. Il reste encore aujourd'hui la fondation de nombreux fournisseurs .NET.

await using var transaction = await connection.BeginTransactionAsync();

try
{
    // Commandes explicites utilisant la même connexion et la même transaction.
    await transaction.CommitAsync();
}
catch
{
    await transaction.RollbackAsync();
    throw;
}

ADO.NET ne promet pas de résoudre le décalage objet-relationnel. Il donne les moyens de communiquer avec le moteur.

DataSet et DataTable

Le DataSet représente des données relationnelles déconnectées en mémoire : tables, colonnes, relations et contraintes. Il s'intégrait remarquablement bien aux designers et au data binding de l'époque.

var dataSet = new DataSet();
var customers = new DataTable("Customers");

customers.Columns.Add("Id", typeof(int));
customers.Columns.Add("Name", typeof(string));

dataSet.Tables.Add(customers);

Cette représentation est centrée sur les données, pas sur un domaine objet riche. Les DataSets typés ont ajouté génération de code et sécurité de typage, tout en conservant cette philosophie tabulaire.

LINQ to SQL

LINQ to SQL a introduit une rupture importante : interroger SQL Server avec des expressions LINQ fortement typées et matérialiser des objets. Son périmètre était plus simple que celui d'Entity Framework et son intégration au langage séduisante.

var activeCustomers =
    from customer in dataContext.Customers
    where customer.IsActive
    orderby customer.Name
    select customer;

LINQ to SQL n'est pas « EF avant EF ». C'est une technologie distincte, largement centrée sur SQL Server et sur un mapping assez direct entre tables et classes.

NHibernate

Avant la maturité d'Entity Framework, NHibernate constituait déjà un ORM complet crédible sur .NET. Il proposait sessions, mappings, lazy loading, requêtes objet et unité de travail. Sa présence montre qu'Entity Framework n'est pas né dans un vide technique ; Microsoft entrait dans un domaine déjà exploré.

Figure 4 — Les outils de persistance forment un continuum. Davantage d'automatisation réduit la plomberie, mais augmente la nécessité de comprendre le comportement de l'abstraction.

L'ambition particulière d'Entity Framework

La première ambition d'Entity Framework dépassait le simple mapping table-classe. Dans une présentation de la Beta 1 d'« Orcas » publiée en 2007, John Papa expliquait que le framework permettait de travailler avec un modèle conceptuel plutôt qu'avec le schéma relationnel logique [4].

Le système distinguait :

un modèle conceptuel représentant les entités utilisées par l'application ;
un modèle de stockage représentant la base ;
une couche de mapping reliant les deux.

Cette ambition explique à la fois la puissance et la lourdeur des premières versions. Entity Framework ne cherchait pas uniquement à économiser du code de mapping. Il cherchait à introduire un modèle de données conceptuel indépendant de l'organisation physique.

La documentation historique définit d'ailleurs l'ADO.NET Entity Framework comme un ensemble de technologies permettant de programmer contre le modèle conceptuel de l'application plutôt que directement contre le schéma relationnel [5].

SQL est resté parce qu'il reste nécessaire

Dire que SQL n'a pas évolué depuis trente ans serait inexact. Les fonctions analytiques, les expressions de table communes, les types JSON, les tables temporelles et de nombreuses capacités propres aux moteurs ont profondément enrichi le langage et ses implémentations, jusqu'aux extensions vectorielles pour le RAG.

Ce qui est resté stable est son socle mental : ensembles, projections, filtres, jointures, agrégations, contraintes et transactions. Cette stabilité rend le SQL explicite et rassurant. Une requête validée et correctement indexée peut vivre longtemps.

Mais écrire tout le code de persistance en SQL ne supprime pas les problèmes de modèle, de transaction ou de concurrence. Cela déplace leur résolution dans le code applicatif et dans la base.

Un ORM est utile lorsqu'il :

réduit effectivement la répétition ;
conserve un SQL raisonnable ;
rend les frontières transactionnelles lisibles ;
autorise une échappatoire vers SQL ;
reste observable ;
ne prétend pas rendre le moteur sans importance.

Il devient nuisible lorsqu'il est utilisé pour éviter d'apprendre la base relationnelle.

À retenir

Le problème central n'est pas la syntaxe SQL, mais la synchronisation entre un graphe d'objets et des ensembles relationnels.
ADO.NET est une API d'accès explicite, pas un ORM incomplet.
Active Record, Data Mapper, Unit of Work et Identity Map sont des patterns, pas des fonctions propres à EF.
Les micro-ORM et les ORM complets occupent des positions différentes sur un continuum d'automatisation.
LINQ to SQL et Entity Framework sont des produits distincts.
La première ambition d'Entity Framework était un modèle conceptuel séparé du modèle de stockage.
Un ORM correctement utilisé ne dispense jamais de comprendre SQL.

Conclusion partielle

La prochaine partie examinera comment cette ambition initiale a produit l'EDMX, pourquoi Code First a changé la source de vérité, et pourquoi EF Core a finalement nécessité une réécriture.
J'espère sincèrement que cette remise à plat à la fois d'une histoire riche en rebondissements et en enseignemens techniques vous donnera, au fil des articles, une vision neuve et complète des ORM dans le monde .NET et ce quest aujoud'hui EF Core, ce qui'il offre vraiment, et ce qu'il n'est pas ou plus.

Stay Tuned!

Références

Hibernate ORM, « A Short Guide to Hibernate 7 », introduction à l'ORM.
Microsoft Learn, « DbContext Lifetime, Configuration, and Initialization », citation et application du pattern Unit of Work.
Hibernate ORM, « Hibernate ORM User Guide », préface et objectifs de conception.
John Papa, « ADO.NET Entity Framework Overview », MSDN Magazine, juillet 2007.
Microsoft Open Specifications, « ADO.NET Entity Framework — Glossary ».
Martin Fowler, « Data Mapper », Patterns of Enterprise Application Architecture.
Martin Fowler, « Active Record », Patterns of Enterprise Application Architecture.
Martin Fowler, « Unit of Work », Patterns of Enterprise Application Architecture.

Vous ne connaissez probablement plus Entity Framework

odahan@e-naxos.com — lun., 28 sept. 2026 13:30:00 +0100

Vingt ans de changements ont rendu une partie de nos certitudes obsolètes.

Série — Entity Framework : remettre les compteurs à zéro
Article d'ouverture. Les quatre articles suivants reviendront sur l'origine des ORM, l'histoire d'Entity Framework, la prise en main d'EF Core et les pratiques nécessaires en production.

Le produit dont vous vous souvenez n'existe peut-être plus

Vous avez utilisé Entity Framework il y a dix ou quinze ans. Vous vous souvenez d'un designer, d'un fichier EDMX, de classes générées et de requêtes SQL parfois surprenantes. Vous avez peut-être adopté Dapper, écrit des procédures stockées ou repris le contrôle avec ADO.NET. Un nouveau projet arrive, quelqu'un propose EF Core, et vous pensez déjà connaître la suite.

Le problème est que le produit dont vous vous souvenez n'existe plus vraiment. Son nom a survécu, certaines idées aussi, mais l'architecture, les outils et une grande partie des compromis ont changé.

Le phénomène inverse existe également. Un développeur ayant commencé avec EF Core peut croire que l'expression « Entity Framework » a toujours désigné un ORM léger, distribué par packages NuGet, configuré en C# et naturellement intégré à l'injection de dépendances. Ce n'est pas davantage exact.

Sous un même nom se cachent plusieurs générations technologiques : le modèle conceptuel ambitieux de l'ADO.NET Entity Framework, le designer EDMX, Database First, Model First, Code First, ObjectContext, DbContext, puis une réécriture multiplateforme qui a d'abord perdu de nombreuses fonctions avant de les reconstruire autrement.

Figure 1 — Plusieurs générations de persistance .NET ont coexisté. La flèche représente une évolution des usages, pas une filiation stricte entre tous les produits.

Les critiques anciennes n'étaient pas imaginaires

Il serait malhonnête de réduire les réticences à un manque de formation. Certaines versions d'Entity Framework ont réellement été lourdes. Le modèle conceptuel avait un coût. Les fichiers EDMX pouvaient devenir difficiles à fusionner. Le lazy loading a provoqué une quantité considérable de problèmes N+1. Certaines traductions LINQ étaient incomplètes ou inefficaces. Les migrations ont parfois été traitées comme un bouton magique de déploiement.

Les débuts d'EF Core ont ajouté une autre couche de confusion. La version 1.0 apportait une architecture nouvelle, mais elle ne remplaçait pas fonctionnellement EF6. Dans son annonce de juin 2016, Rowan Miller recommandait encore EF Core principalement pour les nouvelles applications ne nécessitant pas les fonctionnalités absentes. Il reconnaissait aussi que son fournisseur LINQ était encore en maturation [1]. Ce rappel historique explique pourquoi deux avis opposés pouvaient être vrais au même moment : EF Core représentait l'avenir architectural, tandis qu'EF6 restait souvent le choix fonctionnel le plus complet.

Aujourd'hui, juger EF Core uniquement à partir de cette période serait aussi erroné que de juger C# actuel à partir de C# 2.0. Mais l'excès inverse serait tout aussi mauvais : un ORM mature ne dispense pas de connaître SQL, les index, les transactions ou le moteur réellement utilisé.

Quelques certitudes à réexaminer

Certitude fréquente	Ce qu'il faut vérifier aujourd'hui
« Entity Framework impose un EDMX. »	EF Core utilise généralement des classes C# et une configuration par conventions ou Fluent API.
« Les entités doivent être générées. »	Elles peuvent être de simples classes sans dépendance à EF Core.
« Une requête LINQ charge nécessairement des entités. »	Une projection peut produire directement le DTO utile.
« Tout est suivi en mémoire. »	Le tracking est contrôlable et inutile pour de nombreuses lectures.
« Une mise à jour collective exige de charger toutes les lignes. »	`ExecuteUpdate` et `ExecuteDelete` agissent directement en base.
« Le SQL est caché. »	Les journaux et `ToQueryString()` permettent de l'inspecter.
« EF rend tous les moteurs interchangeables. »	Les fournisseurs partagent un socle, mais conservent des capacités et des traductions différentes.
« Choisir EF interdit SQL ou Dapper. »	Une application peut combiner ces outils par cas d'usage.

La documentation actuelle décrit DbContext comme une unité de travail de courte durée et précise qu'il n'est pas thread-safe [2]. Ce simple point élimine déjà deux erreurs historiques : conserver un contexte pendant toute la durée de vie d'une application, ou partager la même instance entre opérations parallèles.

Une première preuve par le code

Voici un modèle EF Core complet, volontairement réduit :

using Microsoft.EntityFrameworkCore;

public sealed class Customer
{
    public int Id { get; set; }
    public required string Name { get; set; }
}

public sealed class SalesDbContext(
    DbContextOptions<SalesDbContext> options)
    : DbContext(options)
{
    public DbSet<Customer> Customers => Set<Customer>();
}

Sa configuration avec SQLite tient en quelques lignes :

var options = new DbContextOptionsBuilder<SalesDbContext>()
    .UseSqlite("Data Source=sales.db")
    .Options;

await using var db = new SalesDbContext(options);

// Uniquement pour cette démonstration introductive.
// La série utilisera ensuite de véritables migrations.
await db.Database.EnsureCreatedAsync();

L'insertion et la lecture ne nécessitent ni designer ni fichier de mapping :

db.Customers.Add(new Customer { Name = "Contoso" });
await db.SaveChangesAsync();

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

Ce code ne prouve pas qu'EF Core convient à tous les projets. Il montre seulement que les anciennes représentations — designer, XML, génération omniprésente — ne décrivent plus l'expérience ordinaire.

SQLite pour apprendre, le véritable moteur pour valider

Tous les exemples de cette série utiliseront SQLite. Le choix est pratique : aucun serveur à installer, une base dans un fichier, un fonctionnement identique sous Windows, Linux et macOS, et une remise à zéro immédiate.

Changer de fournisseur commence souvent par un package et une méthode de configuration :

// SQLite — fournisseur Microsoft
options.UseSqlite("Data Source=sales.db");

// SQL Server ou Azure SQL — fournisseur Microsoft
options.UseSqlServer(sqlServerConnectionString);

// PostgreSQL — fournisseur Npgsql
options.UseNpgsql(postgreSqlConnectionString);

// Oracle — fournisseur Oracle
options.UseOracle(oracleConnectionString);

Mais il faut refuser la conclusion simpliste selon laquelle seuls ces appels changeraient. La documentation des fournisseurs rappelle qu'ils peuvent étendre EF Core avec des fonctions propres au moteur [3]. SQLite ne prend notamment pas en charge les schémas, les séquences ni les jetons de concurrence générés par la base. Certaines opérations sur decimal, DateTimeOffset et TimeSpan présentent également des restrictions [4].

La règle de la série sera donc la suivante :

SQLite est notre support de démonstration, pas un simulateur universel de SQL Server, PostgreSQL ou Oracle.

Une application de production doit être testée avec son véritable moteur et son véritable fournisseur EF Core.

Ce que cette série cherche à déterminer

La question n'est pas : « EF Core est-il meilleur que SQL ? » Elle est mal posée. EF Core produit du SQL pour les fournisseurs relationnels et permet lui-même d'exécuter du SQL explicite. Les vraies questions sont plus concrètes :

Pourquoi les ORM ont-ils été créés ?
Quel problème Entity Framework cherchait-il initialement à résoudre ?
Pourquoi Microsoft a-t-il choisi une réécriture ?
Qu'est-ce qu'EF Core a conservé, abandonné ou reconstruit ?
Quel est aujourd'hui le code minimal d'une application réaliste ?
Comment éviter le tracking inutile, le N+1 et les graphes chargés sans limite ?
Comment inspecter les requêtes générées ?
Comment gérer les migrations, les transactions et la concurrence ?
Quand faut-il préférer Dapper ou SQL explicite ?

Cette démarche rejoint une remarque intéressante de la documentation Hibernate : à la question « ORM ou SQL ? », sa réponse courte est « use both » [5]. L'opposition absolue est surtout un débat de chapelle. Un ORM sert à supprimer une plomberie répétitive ; SQL reste le langage et le modèle qu'il faut comprendre.

Figure 2 — L'article d'ouverture donne la carte ; les deux articles suivants expliquent l'histoire ; les deux derniers construisent puis durcissent la pratique.

Le parcours proposé

Partie 1 — Pourquoi avons-nous inventé les ORM ?

Nous repartirons du décalage entre graphes d'objets et données relationnelles. Nous comparerons mapping manuel, Active Record, Data Mapper, ORM complet et micro-ORM, puis replacerons ADO.NET, DataSet, LINQ to SQL et NHibernate dans le paysage .NET.

Partie 2 — D'Entity Framework à EF Core : histoire d'une réécriture

Nous reviendrons sur l'ambition initiale du modèle conceptuel, l'EDMX, Database First, Model First, Code First, DbContext, les migrations et la réécriture EF Core. Le but ne sera pas de réciter toutes les versions, mais d'expliquer les ruptures et leurs raisons.

Partie 3 — EF Core aujourd'hui : du projet vide à SQLite

Nous construirons une petite application de gestion commerciale avec .NET 10, EF Core 10 et SQLite : entités, relations, configuration, migrations, insertions, lectures, projections, modifications et inspection du SQL.

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

Nous passerons du code qui fonctionne au code maîtrisé : durée de vie du contexte, tracking, N+1, requêtes fractionnées, pagination, opérations ensemblistes, concurrence, transactions, SQL brut, tests et migrations en production.

Le contrat de lecture

Cette série ne cherchera pas à prouver qu'EF Core est toujours le bon choix. Ce serait faux. Elle cherchera à permettre une évaluation fondée sur ce qu'EF Core est devenu, non sur ce qu'Entity Framework était il y a dix ou quinze ans.

Nous commencerons donc par le problème d'origine : pourquoi avons-nous voulu faire correspondre des objets à des tables, et pourquoi cette opération apparemment simple a-t-elle engendré autant de solutions différentes ?

Références

Rowan Miller, « Announcing Entity Framework Core 1.0 », Microsoft .NET Blog, 27 juin 2016.
Microsoft Learn, « DbContext Lifetime, Configuration, and Initialization ».
Microsoft Learn, « Database Providers ».
Microsoft Learn, « SQLite EF Core Database Provider Limitations ».
Hibernate ORM, « A Short Guide to Hibernate 7 », section d'introduction sur ORM et SQL.
Microsoft Learn, « What's New in EF Core 10 ». EF Core 10 est une version LTS publiée en novembre 2025 et prise en charge jusqu'au 10 novembre 2028.

Conclusion partielle

J'ai conçui cette série car moi-même je n'y voyais plus très clair. Peu de mes clients utilisent encore Entity Framework et encore, juste en mode legacy, et très peu utilisent EF Core. En tant que MVP depuis presque 20 ans j'ai connu toutes les versions, et même pire pour moi et mes collègues partageant ce titre, j'ai connu toutes les previews, les breaking changes avant même les releases finales connues du public. Autant dire que des "morceaux" d'Entity Framework, ma mémoire en a entassés des tas et que tout cela devient un bouillie de souvenirs qui ne reflètent pas avec justice ce qu'est EF Core aujourd'hui qui paye le prix de son héritage. C'est avant tout pour y voir clair que je me suis remplongé dans l'histoire d'Entity Framework, sa raison d'être, ses différentes incarnations, et surtout ce qu'est devenu EF Core pour savoir s'il est ou non utilisable et quel est son véritable périmètre. Ainss, cette série d'articles est un voyage dans l'histoire d'un produit, d'une fonctionnalité, de méthodes différentes, pour aboutir à ce que vous devez savoir aujourd'hui d'EF Core, en toute justice et toute exactitude technique.
A la semaine prochaine, même lieu, même heure, pour le prochain volet de cette aventure !

Stay Tuned!

NuGet : Microsoft change son certificat de signature — faut-il modifier vos builds ?

odahan@e-naxos.com — lun., 28 sept. 2026 01:00:00 +0100

Microsoft vient de changer le certificat utilisé pour signer ses packages NuGet. Dit comme cela, l'information paraît suffisamment obscure pour être classée dans la catégorie « sécurité d'infrastructure, quelqu'un d'autre s'en occupera ».

Ce serait pourtant une mauvaise idée.

Pas parce que tous nos projets .NET vont brutalement cesser de compiler — ce n'est absolument pas le cas — mais parce que certains environnements ayant correctement durci leur chaîne d'approvisionnement NuGet peuvent, eux, commencer à refuser les nouveaux packages Microsoft.

Le paradoxe est assez amusant : ce sont précisément les équipes ayant mis en place les contrôles de sécurité les plus stricts qui doivent vérifier leur configuration.

Microsoft a annoncé le changement le 23 septembre 2026. Je vais donc regarder ce qui change réellement, qui est concerné et ce qu'il faut vérifier.

Ce qui change exactement

Microsoft signe ses packages NuGet avec un certificat X.509.

À partir du 23 septembre 2026, un nouveau certificat devient le certificat utilisé par défaut pour les nouvelles signatures d'auteur Microsoft.

L'empreinte SHA-256 du nouveau certificat est :

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

L'empreinte du certificat précédemment utilisé était :

566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

Et c'est là qu'un premier détail a son importance : les packages déjà publiés ne sont évidemment pas resignés avec le nouveau certificat.

Un ancien package conserve donc son ancienne signature.

Autrement dit, la transition ne ressemble pas à ceci :

Ancien certificat
       |
       X
       |
Nouveau certificat

mais plutôt à ceci :

Packages déjà publiés
        |
        +---- signés avec certificat A
        |
        +---- signés avec certificat B
        |
        +---- signés avec certificat C

Nouveaux packages Microsoft
        |
        +---- signés avec certificat D
              à partir de septembre 2026

Une politique de confiance correcte doit donc être capable d'accepter plusieurs générations de certificats Microsoft simultanément.

C'est une nuance importante : remplacer l'ancienne empreinte par la nouvelle serait une erreur.

Il faut ajouter la nouvelle.

Est-ce que je suis concerné ?

C'est la première question à poser, car il ne faut surtout pas transformer cette annonce en alerte générale.

Dans la majorité des environnements .NET classiques, il n'y a rien à faire.

Microsoft indique que le changement concerne principalement deux cas. Le premier est celui où NuGet est configuré avec une politique de signataires approuvés — les fameux trustedSigners.
Le second concerne les scripts ou pipelines utilisant explicitement :

dotnet nuget verify

avec une ou plusieurs empreintes de certificats Microsoft.

Si vous n'utilisez ni l'un ni l'autre, les packages Microsoft signés avec le nouveau certificat doivent continuer à s'installer normalement.
Donc avant de modifier quoi que ce soit : regardez votre configuration.

Un petit rappel sur les signatures NuGet

Une signature de package ne sert pas simplement à indiquer que « le fichier vient de Microsoft ».

Elle permet notamment de vérifier deux choses fondamentales :

l'identité cryptographique du signataire ;
l'intégrité du package depuis sa signature.

Le package contient sa signature. Le client NuGet peut ensuite décider jusqu'où il souhaite pousser la vérification.

On peut schématiser grossièrement le mécanisme ainsi :

             Package .nupkg
                    |
                    v
             Signature NuGet
                    |
           +--------+--------+
           |                 |
           v                 v
      Intégrité        Certificat du
      du package        signataire
                             |
                             v
                     Politique NuGet
                             |
                    +--------+--------+
                    |                 |
                 accepté            refusé
                    |                 |
                    v                 v
                 restore          NU3034

Le point intéressant est donc la dernière étape.

Une organisation peut parfaitement décider :

Je n'accepte pas simplement un package parce que sa signature cryptographique est valide. Je veux aussi vérifier que son signataire appartient à une liste explicitement approuvée.

C'est précisément le rôle de trustedSigners.

`signatureValidationMode=require`

NuGet permet de renforcer la validation avec une configuration de ce genre :

<configuration>
  <config>
    <add key="signatureValidationMode" value="require" />
  </config>

  <trustedSigners>
    ...
  </trustedSigners>
</configuration>

Avec :

signatureValidationMode="require"

les packages doivent correspondre aux règles définies dans trustedSigners.

On peut approuver un auteur ou un repository.

Pour Microsoft, une politique basée sur l'auteur peut par exemple ressembler à ceci :

<trustedSigners>
  <author name="Microsoft">
    <certificate
      fingerprint="3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE"
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />

    <certificate
      fingerprint="AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27"
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />

    <certificate
      fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />

    <certificate
      fingerprint="9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630"
      hashAlgorithm="SHA256"
      allowUntrustedRoot="false" />
  </author>
</trustedSigners>

La dernière ligne est donc celle correspondant au nouveau certificat.

Mais observez bien que Microsoft conserve également les trois empreintes précédentes.

Ce n'est pas un détail d'implémentation : c'est indispensable si l'on veut continuer à restaurer d'anciens packages Microsoft.

Ce qu'il ne faut pas faire : remplacer l'ancienne empreinte

Imaginons une politique simplifiée :

<author name="Microsoft">
  <certificate
    fingerprint="566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353"
    hashAlgorithm="SHA256"
    allowUntrustedRoot="false" />
</author>

On pourrait être tenté de remplacer cette empreinte par la nouvelle.
Ce serait faux. On obtiendrait :

Ancien package Microsoft
         |
         v
signature certificat 566A...
         |
         v
empreinte absente de trustedSigners
         |
         X
       refus

Alors que la bonne politique est :

                 Microsoft
                     |
         +-----------+-----------+
         |                       |
    ancien certificat       nouveau certificat
         |                       |
       accepté                  accepté

Une rotation de certificat ne signifie donc pas automatiquement « supprimer l'ancien ». Elle signifie ici étendre l'ensemble des identités cryptographiques acceptées.

La méthode la plus simple avec le SDK .NET

Il n'est heureusement pas indispensable d'éditer le XML à la main. Avec un SDK .NET suffisamment récent, Microsoft indique d'utiliser :

dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 --algorithm SHA256

La commande met à jour le fichier nuget.config concerné.

Et si, comme je le recommande dans un environnement maîtrisé, vous souhaitez désigner explicitement celui qui doit être modifié :

dotnet nuget trust author Microsoft 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630 \
  --algorithm SHA256 \
  --configfile ./NuGet.config

Sous PowerShell ou cmd.exe, il faudra naturellement adapter la continuation de ligne ou saisir la commande sur une seule ligne.

Je préfère cette méthode à une modification manuelle dès qu'elle peut être utilisée : elle réduit les erreurs de saisie sur une empreinte SHA-256 qui, soyons francs, n'est pas le genre de chaîne que l'on souhaite recopier à la main.

Et `dotnet nuget verify` ?

Deuxième cas : certains pipelines vérifient explicitement les packages téléchargés. On peut par exemple utiliser :

dotnet nuget verify MonPackage.nupkg

pour vérifier un package signé.

Mais on peut aller plus loin et exiger une empreinte précise :

dotnet nuget verify MonPackage.nupkg \
  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353

Dans ce cas, un nouveau package Microsoft signé avec le certificat de septembre 2026 ne correspondra évidemment plus à cette empreinte.
Là encore, il ne faut pas simplement remplacer l'ancienne valeur.

dotnet nuget verify accepte plusieurs options --certificate-fingerprint.

On peut donc écrire :

dotnet nuget verify MonPackage.nupkg \
  --certificate-fingerprint 3F9001EA83C560D712C24CF213C3D312CB3BFF51EE89435D3430BD06B5D0EECE \
  --certificate-fingerprint AA12DA22A49BCE7D5C1AE64CC1F3D892F150DA76140F210ABD2CBFFCA2C18A27 \
  --certificate-fingerprint 566A31882BE208BE4422F7CFD66ED09F5D4524A5994F50CCC8B05EC0528C1353 \
  --certificate-fingerprint 9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

C'est particulièrement important si cette commande apparaît dans un script CI/CD.

Le vrai risque : le `restore` qui casse sans modification du code

C'est finalement ce que je trouve intéressant dans cette annonce.

On peut avoir :

le même dépôt Git ;
le même code source ;
le même SDK ;
le même csproj ;
la même version d'une dépendance directe ;

et pourtant voir un pipeline échouer simplement parce qu'un package nouvellement restauré est désormais signé avec un certificat qui n'existe pas dans la politique de confiance locale.

Le scénario peut ressembler à ceci :

                   Hier
                     |
              dotnet restore
                     |
         package Microsoft signé
         certificat autorisé
                     |
                     v
                    OK


                 Aujourd'hui
                     |
              dotnet restore
                     |
         nouveau package Microsoft
          nouveau certificat
                     |
         certificat absent de
            trustedSigners
                     |
                     v
                  NU3034

Ce genre d'incident est trompeur parce que rien n'a nécessairement changé dans l'application. C'est l'environnement de confiance de la chaîne de build qui a changé.
Et c'est précisément pour cette raison que les dépendances, les feeds NuGet et leurs règles de validation font partie de l'infrastructure de build au même titre que le SDK ou MSBuild.

Comment savoir rapidement si votre entreprise est concernée ?

Je commencerais par chercher les éléments suivants dans les dépôts et dans les configurations des agents de build :

signatureValidationMode
trustedSigners
certificateFingerprint
--certificate-fingerprint
dotnet nuget verify
nuget verify

La présence de :

<add key="signatureValidationMode" value="require" />

mérite évidemment une attention immédiate.

De même pour :

<trustedSigners>

Dans une organisation importante, attention à ne pas chercher uniquement dans le nuget.config placé à la racine de la solution.
NuGet combine potentiellement plusieurs niveaux de configuration. Une règle peut donc provenir d'un fichier situé en dehors du dépôt lui-même et être appliquée sur les postes de développement ou sur les agents CI.
C'est même souvent là que les surprises commencent.

CI/CD : GitHub Actions, Azure DevOps, Jenkins…

Le moteur CI utilisé n'a finalement que peu d'importance.
GitHub Actions, Azure DevOps, Jenkins ou un agent interne ne sont affectés que dans la mesure où les commandes exécutées par le pipeline le sont.
Prenons un pipeline extrêmement simplifié :

steps:
  - script: dotnet restore
    displayName: Restore

  - script: dotnet build --no-restore
    displayName: Build

  - script: dotnet test --no-build
    displayName: Tests

Si le dotnet restore utilise un nuget.config imposant les signataires autorisés et que le nouveau certificat Microsoft n'y figure pas, le pipeline peut échouer dès la première étape.
Le correctif n'est alors ni dans le csproj, ni dans le code C#, ni dans le YAML lui-même.
Il est dans la politique NuGet.
C'est une distinction qui peut faire gagner pas mal de temps lorsque l'incident survient.

Faut-il installer le nouveau certificat dans le magasin Windows ?

C'est une confusion assez naturelle, car dès que l'on parle de X.509 sous Windows on pense immédiatement à certmgr.msc, certlm.msc, TrustedPeople, TrustedRoot, PowerShell ou certutil.

Mais ce n'est pas ce que demande Microsoft pour cette rotation.

Dans le scénario qui nous intéresse ici, l'autorisation du signataire est définie dans la politique NuGet via l'empreinte du certificat.
Il ne faut donc pas transformer cette opération en déploiement sauvage du certificat dans Trusted Root Certification Authorities.
Ce serait au mieux inutile et, au pire, une modification beaucoup plus large de la politique de confiance de la machine que ce dont NuGet a réellement besoin. Une règle de sécurité devrait toujours être appliquée au niveau le plus étroit possible.

Ici :

Je fais confiance à ce certificat
pour identifier cet auteur NuGet

est beaucoup plus précis que :

Je modifie globalement
les autorités auxquelles fait confiance
cette machine.

Ce n'est pas du tout la même chose.

Et si nous n'avons jamais configuré `trustedSigners` ?

Alors il ne faut probablement rien faire.

C'est important de le répéter, parce que les annonces de sécurité ont parfois un effet secondaire regrettable : elles déclenchent des modifications « préventives » sur des machines qui n'étaient pas concernées. Ajouter des règles de confiance que l'on ne comprend pas n'améliore pas la sécurité. Avant toute intervention, je suivrais donc ce raisonnement :

Utilisons-nous trustedSigners ?
             |
        +----+----+
        |         |
       NON       OUI
        |         |
        v         v
   rien à faire   la nouvelle empreinte
                  Microsoft est-elle présente ?
                           |
                      +----+----+
                      |         |
                     OUI       NON
                      |         |
                      v         v
                     OK       l'ajouter

Même raisonnement pour dotnet nuget verify.

Une bonne occasion de regarder enfin nos `nuget.config`

Cette rotation de certificat est finalement assez banale. Les certificats expirent. Les clés tournent. Les fournisseurs modifient leurs infrastructures. Il n'y a là rien d'exceptionnel. Mais elle met en lumière quelque chose que je trouve beaucoup plus intéressant : combien d'équipes savent réellement quelles règles NuGet sont appliquées lors de leurs builds ?

Nous surveillons généralement :

la version du SDK .NET ;
les workloads ;
les versions de packages ;
les sources NuGet ;
parfois les vulnérabilités des dépendances.

Mais beaucoup moins :

les politiques de signature ;
les signataires approuvés ;
les configurations NuGet héritées ;
les différences entre un poste développeur et un agent CI ;
les scripts de vérification ajoutés il y a trois ans et oubliés depuis.

Or tout cela fait partie de la reproductibilité d'un build.

Deux machines exécutant exactement :

dotnet restore

ne suivent pas nécessairement la même politique si elles ne chargent pas les mêmes configurations NuGet. À mes yeux, c'est probablement la leçon la plus intéressante de cette petite rotation de certificat.

Ce que je ferais concrètement

Si je devais vérifier aujourd'hui un environnement .NET professionnel, je resterais très pragmatique :

rechercher trustedSigners et signatureValidationMode dans les configurations NuGet ;
rechercher les utilisations de dotnet nuget verify et nuget verify dans les scripts et pipelines ;
identifier les vérifications fondées sur les empreintes Microsoft ;
ajouter la nouvelle empreinte SHA-256 sans supprimer les anciennes ;
exécuter un vrai dotnet restore sur les agents concernés ;
conserver la configuration dans le contrôle de source lorsque cela est possible.

Ce dernier point est important.
Une politique de sécurité présente uniquement sur un serveur de build et modifiée manuellement par un administrateur est difficile à auditer et encore plus difficile à reproduire. Lorsque le contexte le permet, je préfère de loin :

Repository
   |
   +-- NuGet.config
   |
   +-- src/
   |
   +-- tests/
   |
   +-- pipeline.yml

à une configuration invisible dispersée dans les machines.

Ce qui peut être versionné, revu et audité devrait généralement l'être.

En conclusion

Il n'y a pas ici de faille spectaculaire, ni d'urgence généralisée dans l'écosystème .NET.
Microsoft fait tourner son certificat de signature d'auteur pour ses packages NuGet, et la plupart des développeurs ne verront absolument aucune différence.
En revanche, si votre organisation utilise une politique stricte de signataires approuvés ou vérifie explicitement les empreintes des certificats Microsoft, il faut ajouter le nouveau certificat à la liste des certificats autorisés.

L'empreinte SHA-256 à ajouter est :

9A1B131BEE0605433056A4EA3815478A8E177961A968C6C0027C1093D1FEB630

Et je souligne une dernière fois le point le plus facile à rater :

Ajoutez cette empreinte. Ne remplacez pas les anciennes.

Les anciens packages restent signés avec leurs anciens certificats.

Au-delà de cette modification ponctuelle, j'y vois surtout une bonne occasion de regarder d'un peu plus près nos nuget.config.
La supply chain logicielle n'est pas uniquement constituée des packages que nous choisissons d'utiliser. Elle comprend également les règles qui déterminent qui nous autorisons à nous fournir ces packages. Et cette partie-là mérite probablement davantage d'attention qu'on ne lui en accorde habituellement.

Références

Microsoft .NET Blog — Microsoft is updating its author-signing certificate starting September 23, 2026, NuGet Team, 23 septembre 2026.
Microsoft Learn — référence du fichier nuget.config, section trustedSigners.
Microsoft Learn — commande dotnet nuget verify.
Microsoft Learn — gestion des limites de confiance pour les packages signés.

Stay Tuned!

Spec Kit, SDD et la plomberie : quand l’industrialisation devient-elle contre-productive ?

odahan@e-naxos.com — ven., 25 sept. 2026 13:00:00 +0100

Le Spec-Driven Development commence à s’installer dans le paysage du développement assisté par IA. L’idée générale est séduisante : plutôt que de multiplier les prompts éphémères et de laisser progressivement le code devenir la seule description réelle du logiciel, on conserve l’intention dans des spécifications explicites, vivantes et révisables.

Microsoft décrit aujourd’hui le SDD comme une approche dans laquelle les spécifications deviennent une source de vérité partagée entre humains et IA, reliant l’intention métier, les contraintes, l’architecture, l’implémentation et la validation. Microsoft recommande d’ailleurs explicitement de commencer léger et d’étendre le processus uniquement lorsqu’il apporte une valeur claire.

Jusque-là, tout paraît assez simple.

Puis arrive GitHub Spec Kit.

Et soudain apparaissent commandes, templates, CLI, scripts, presets, extensions, workflows et différentes structures documentaires.

D’où une question assez naturelle :

si le SDD repose principalement sur des fichiers que les humains et les agents savent lire et modifier, pourquoi faut-il toute cette plomberie ?

La réponse est intéressante, parce qu’elle permet à la fois de mieux comprendre Spec Kit et de mieux comprendre ce que SDD n’impose pas.

SDD n’est pas Spec Kit

La première distinction à faire est probablement la plus importante.

Le SDD est une manière d’organiser le développement autour d’une intention explicite et durable. GitHub Spec Kit est une manière particulière de matérialiser cette approche.

Microsoft lui-même présentait dès 2025 Spec Kit comme une implémentation apportant notamment une CLI de bootstrap, des templates et des scripts auxiliaires. Les documents produits restent essentiellement des fichiers Markdown que l’on peut consulter et modifier directement.

Autrement dit, on pourrait tout à fait pratiquer une forme de SDD avec seulement quelques artefacts :

PROJECT.md
RULES.md
SPEC.md
STATUS.md

et un agent auquel on donne des instructions explicites pour les lire, les maintenir et travailler à partir d’eux.

Il n’existe pas de nécessité conceptuelle imposant une CLI, GitHub ou une chaîne complexe de commandes (et encore moins python ou des scripts powershell).

Spec Kit ajoute autre chose.

Il ajoute de la reproductibilité.

À quoi sert alors toute cette plomberie ?

Le workflow SDD actuel de Spec Kit peut aller de la constitution jusqu’à la convergence, en passant par la spécification, la clarification, le plan, les tâches, les checklists, l’analyse et l’implémentation.

Une partie importante de ce fonctionnement ne consiste pas à « comprendre le logiciel ». Elle consiste à automatiser une mécanique autour des artefacts :

initialiser correctement un projet ;
installer les commandes adaptées à l’agent utilisé ;
retrouver les bons fichiers ;
déterminer la feature courante ;
appliquer les bons templates ;
vérifier les prérequis entre étapes ;
maintenir des conventions communes ;
fournir les mêmes procédures à différents agents et différentes équipes.

Ce travail n’est pas inutile. Au contraire.

Il déplace hors du LLM tout ce qui peut être rendu déterministe.

Le principe est sain :

raisonnement et sémantique   → agent / LLM
mécanique reproductible      → code
intention durable            → artefacts

La question n’est donc pas de savoir si Spec Kit est bien ou mal conçu.

La question est : de quelle quantité de cette infrastructure avons-nous réellement besoin ?

La complexité traitée par Spec Kit n’est pas seulement celle du logiciel

C’est probablement là que se trouve la clé.

Une petite équipe composée de quelques développeurs expérimentés travaillant ensemble depuis longtemps peut avoir un logiciel techniquement très complexe tout en ayant peu de problèmes de coordination.

À l’inverse, une application relativement banale répartie entre plusieurs équipes, prestataires, technologies et agents IA peut devenir extraordinairement difficile à gouverner.

Spec Kit apporte surtout de la valeur lorsque le nombre de points de coordination augmente :

x nombre d'acteurs
x hétérogénéité des acteurs
x parallélisme
x turnover
x durée du projet
x contraintes organisationnelles

Lorsque ce produit devient important, transformer une manière de travailler en protocole reproductible a beaucoup de sens.

La plomberie réduit alors la variance.

L’équipe A ne travaille plus totalement différemment de l’équipe B. Un nouvel agent retrouve les mêmes conventions. Un intervenant qui arrive six mois plus tard dispose des mêmes structures. Une organisation peut appliquer certaines règles de manière homogène.

Dans ce contexte, Spec Kit ne constitue pas une complication accidentelle.

Sa complexité répond à une complexité organisationnelle réelle. Mais on verra plus loin que cela peut être illusoire...

Le parallèle avec GitHub est frappant

On retrouve ici un phénomène déjà observable depuis longtemps autour des outils de gestion de sources.

Git, GitHub, les Pull Requests, les workflows automatisés, les branches, les checks, CODEOWNERS, les issues et toute l’infrastructure qui les accompagne sont extraordinairement adaptés à certains contextes.

Pour un grand projet open source réunissant des centaines ou des milliers de contributeurs répartis autour de la planète, le problème de coordination est immense. La plomberie est justifiée.

Cela ne signifie pas que chaque équipe de quatre développeurs travaillant sur trois applications métier ait besoin du même niveau de processus. Subversion était parfaitement taillé pour ces contextes par exemple.

La généralisation d’une solution conçue pour résoudre les problèmes d’une grande échelle peut transformer une excellente architecture organisationnelle en bureaucratie.

Spec Kit pose exactement la même question.

Il ne faut pas confondre :

« Cet outil sait coordonner un environnement complexe »

avec :

« Toute équipe doit adopter cet environnement complexe pour travailler correctement ».

Le retour du coût de confiance

Il existe également une autre dimension, plus rarement discutée : celle de la chaîne de confiance.

Spec Kit n’impose désormais plus Git dans tous les cas ; la documentation actuelle indique que Git est optionnel et principalement requis lorsque l’extension correspondante est utilisée. En revanche, l’installation officielle de Spec Kit demande actuellement Python 3.11+ ainsi que uv ou pipx.

Le problème n’est évidemment pas Python.

Une équipe Python ne se poserait même pas la question.

Mais considérons une équipe entièrement .NET.

Son environnement maîtrisé peut être constitué de :

.NET SDK
PowerShell
Visual Studio / Rider
quelques packages connus
ses propres applications

L’adoption d’un outil externe ajoute alors une nouvelle chaîne :

Python
→ gestionnaire de packages Python
→ specify-cli
→ dépendances
→ templates
→ scripts
→ mécanismes de mise à jour

Encore une fois, cela peut être parfaitement justifié.

Mais il faut le justifier.
Et le justifier par "c'est parce que tout le monde le fait", n'est pas une justification acceptable.

Une règle élémentaire d’architecture devrait également s’appliquer à l’outillage :

Toute dépendance ajoutée à la chaîne de production doit apporter davantage de valeur que le coût de confiance, de compréhension et de maintenance qu’elle introduit.

Or l’un des messages centraux de la gouvernance des agents consiste précisément à ne pas déléguer aveuglément : rendre les règles visibles, connaître le contexte fourni à l’agent, contrôler ce qu’il peut faire, vérifier ses résultats et comprendre les mécanismes automatisés.

Installer un outil de gouvernance sans comprendre ce qu’il gouverne serait donc assez paradoxal.

Ce n’est cependant pas un défaut intrinsèque de Spec Kit

Il serait injuste d’en conclure que Spec Kit est opaque par nature.

Ses artefacts, templates et scripts sont inspectables. Il est possible d’épingler des versions, d’adapter les templates et de modifier les conventions. Je modulerai malgré tout le côté "inspectable" : des développeurs .NET n'iront pas mettre leur nez dans le code Python, et ils ne devraient pas avoir à le faire. De fait c'est comme ces gros packages de contrôles pour WinUI, ASP.Core ou autre qui vous indiquent fièrement que leur code source est fourni, comme élément de confiance. C'est un leurre, avez-vous déjà mis le nez dans ce type de code source de dizaines de milliers de lignes ou plus (surtout qu'on achète ces contrôles souvent parce qu'on ne saurait pas les écrire !) ? Personne ne le fait, bien entendu. Donc quand Spec-kit se dit "inspectable", cela est réservé éventuellement au petit monde des devs Python, mais semble plus être un argument marketing dès qu'on s'adresse à des devs Java ou C#...

GitHub a également introduit un preset lean qui réduit explicitement le workflow à l’essentiel : spécification, plan, tâches et implémentation, avec des fichiers Markdown beaucoup plus directs.

Le système de presets permet en outre de remplacer les templates, commandes et terminologies sans modifier le cœur de l’outil. Déjà là on se sent paumé et pourtant c'est la version "pour les nuls" !

Cela montre justement que Spec Kit reconnaît plusieurs niveaux de cérémonie possibles. Mais cela reste des cérémonies tout de même, et elles ne sont pas forcément justifiée dans tous les cas.

On se moque souvent, et La Fontaine l'a fait avec habileté, de la grenouille que veut se faire aussi grosse que le boeuf, spoiler alert : ça finit mal. S'il avait été notre contemporain Spec-Kit lui aurait peut être inspiré une autre fable tout aussi moralisatrice sur le boeuf qui voulait se faire aussi petit que la grenouille. Et ça finirait mal aussi... Spec-Kit comme GitHub ont été conçu comme des boeufs, dès le départ, pour tirer de lourdes charges. Ils sont utiles et même précieux dans ce cas précis. Mais vouloir les miniaturiser pour les rendre moins impressionnant ne marche pas. Sur les routes on n'utilise pas des "mini locomotives" on a inventé les voitures. Non pas que les locos étaient mal conçues ou inutiles, juste parce qu'en faire des versions miniatures n'avait aucun sens, il fallait repenser le produit tout simplement...

Une organisation peut parfaitement adopter une version donnée de Spec-Kit, l’auditer, la figer, éventuellement la forker, puis l’intégrer à sa propre chaîne d’outillage. C'est possible, c'est souple. Mais, du coup (horrible expression à la mode), un autre paradoxe apparait : Qu'en est-il de la fameuse uniformité qu'apporterait Spec-kit si chacun peut en bricoler une version différente ?

Mais on pourrait dire : dans ce cas, il n’y a aucune contradiction avec les principes de gouvernance.

Au contraire : l’outil de gouvernance est lui-même gouverné.
Sauf qu'il en existe autant de versions que d'équipes et donc adieu l'argument principal d'uniformisation du process ! On a un borderl mais gouverné. C'est possible. Les pays qui n'ont pas suivi la pudibonderie ridicule de la France et qui ont conservé des maisons closes savent très bien qu'un bordel peut être bien gouverné mais que cela n'en change pas la nature en boulangerie ou en centre de loisir pour les écoles du coin...

Là se trouve le vrai paradoxe

Et c’est probablement la conclusion la plus intéressante.

Plus on utilise Spec Kit dans un environnement exigeant (entendez très gros), plus son infrastructure devient justifiée.

Mais plus cette infrastructure devient importante, plus elle doit elle-même être comprise, auditée, versionnée et gouvernée. Sinon elle contredit les principes de base de gouvernance de SDD !

Autrement dit :

Pour utiliser correctement un outil destiné à gouverner le travail des agents, il faut commencer par gouverner cet outil.

Ce paradoxe n’est pas une condamnation de Spec Kit.

Il permet plutôt de replacer l’outil à sa juste place.

Spec Kit est une réponse élaborée à un problème de coordination élaboré. Il exige donc une organisation pour lui-même, une bureaucratie qui s'occupe de faire tourner l'administration, s'auto-justifiant presque de façon absurde.

Le problème commence lorsque cette réponse devient une prescription indépendante du contexte.

Le bon niveau de SDD n’est donc pas universel

Une petite équipe pourrait parfaitement fonctionner avec :

quelques fichiers Markdown
+ des règles explicites
+ un agent

Une équipe intermédiaire pourrait ajouter :

templates
+ contrôles
+ quelques commandes déterministes

Une organisation importante pourrait préférer :

workflow complet
+ contrôles automatiques
+ intégrations multiples
+ conventions partagées
+ Spec Kit ou un système comparable

Ces trois approches peuvent relever du SDD.

Le critère ne devrait pas être la conformité à un outil particulier.

Il devrait être :

Quel niveau de gouvernance faut-il pour conserver l’intention, maîtriser les agents et coordonner correctement les acteurs de ce projet ?

C’est probablement le point essentiel.

SDD permet aux LLM de supprimer une partie de la plomberie autrefois nécessaire pour traduire une intention en comportement logiciel.

Il serait dommage de profiter de cette simplification pour reconstruire immédiatement une infrastructure complexe partout, y compris là où elle ne résout aucun problème réel.
C'est peut-être là un réflexe des incompétents, souvent nombreux dans les hiérarichies (lire le principe de Peter, toute personne est propulsée dans la hiérarchie jusqu'à atteindre son niveau d'incompétence...). Trop simplifié, trop supprimer de bureaucratie rend ceux qui s'en occupait inutiles. Et ils n'aiment pas se sentir sur un siège éjectable, alors ils inventent une nouvelle bureaucratie pour se maintenir en place. Peut-être. Je n'affirme rien, à chacun de constater autour de lui.

En tout cas la bonne gouvernance n’est pas celle qui ajoute le plus de contrôles.

C’est celle qui ajoute exactement les contrôles dont le contexte a besoin — et pas davantage.

Bon projets avec SDD (bien digéré et pas imposé par un outil),

Stay Tuned!

Sécurité des Agents IA : Pourquoi le Prompt ne remplacera JAMAIS vos autorisations (RBAC)

odahan@e-naxos.com — ven., 25 sept. 2026 00:34:00 +0100

Dès qu'un agent IA dispose d’outils (tools) pour interagir avec vos systèmes — créer une note, exporter un rapport financier ou supprimer un ticket support —, la question centrale n'est plus seulement « mon prompt est-il clair ? », mais « cette action est-elle autorisée ? ».

Pourtant, dans beaucoup de prototypes, l'erreur classique consiste à exposer toutes les fonctions de l'entreprise au modèle, puis à ajouter une consigne dans le prompt du type : « N'utilise la fonction de suppression que si l'utilisateur est administrateur ».

Si vous procédez ainsi en production, vous vous exposez à de graves failles de sécurité.

Le problème du « faux confort » du prompt

Un prompt sert à guider le comportement du LLM, pas à garantir la sécurité. Entre les risques de prompt injection, le jailbreaking ou simplement de mauvaises interprétations par le modèle, s'en remettre au LLM pour gérer vos autorisations est une hérésie architecturale.

Le rôle de l'agent est de choisir la meilleure option parmi des actions préalablement autorisées, pas de définir lui-même la politique d'accès aux données et ressources de l'entreprise.

La solution : Le filtrage de catalogue & le double verrou

Pour sécuriser un agent IA, il faut appliquer les principes du RBAC (Role-Based Access Control) dès sa conception :

UserContext $\rightarrow$ Permissions -> Outils autorisés : On ne construit pas un agent omnipotent qu'on tente de brider ensuite. Le système évalue l'utilisateur courant, détermine ses permissions (ex: CanDeleteTicket) et ne fournit à l'agent que le catalogue de tools correspondant à son profil.
Le double verrou à l'exécution : Filtrer le catalogue en entrée ne suffit pas. Même si un tool sensible est présent dans le catalogue d'un administrateur, la fonction elle-même doit revérifier les droits et valider les paramètres au moment de son exécution dans le code métier.

Découvrez la mise en pratique dans ma nouvelle vidéo !

Dans l'Épisode 6 de notre série dédiée à l'architecture des agents IA, nous décortiquons ce pattern indispensable et montrons comment l'implémenter concrètement.

Au programme de la vidéo :

⚠️ Anti-patterns fréquents et pièges à éviter (les tools trop génériques comme ExecuteSql ou HttpPost).
📊 Exemple d'une Matrice RBAC adaptée aux agents.
💻 Démo technique Visual Studio : Illustration du filtrage de catalogue selon le rôle (anonymous vs admin).
⚙️ Transposition dans Microsoft Agent Framework : Comment injecter le UserContext et construire vos function tools de manière sécurisée.
📋 Checklist de production pour valider vos déploiements.

🎥 Visionnez dès maintenant la vidéo complète sur YouTube :

👉 Regarder l'épisode : Filtrer les tools selon les droits

Stay Tuned!

Dot.Blog

Pourquoi avons-nous inventé les ORM ?

Un objet n'est pas une ligne

Ce que coûte réellement le mapping manuel

Les patterns existaient avant les produits

Active Record

Data Mapper

Unit of Work

Identity Map

De l'ORM complet au micro-ORM

Hors de Microsoft : plusieurs réponses au même problème

Chez Microsoft : avant Entity Framework

ADO puis ADO.NET

DataSet et DataTable

LINQ to SQL

NHibernate

L'ambition particulière d'Entity Framework

SQL est resté parce qu'il reste nécessaire

À retenir

Conclusion partielle

Références

Vous ne connaissez probablement plus Entity Framework

Le produit dont vous vous souvenez n'existe peut-être plus

Les critiques anciennes n'étaient pas imaginaires

Quelques certitudes à réexaminer

Une première preuve par le code

SQLite pour apprendre, le véritable moteur pour valider

Ce que cette série cherche à déterminer

Le parcours proposé

Partie 1 — Pourquoi avons-nous inventé les ORM ?

Partie 2 — D'Entity Framework à EF Core : histoire d'une réécriture

Partie 3 — EF Core aujourd'hui : du projet vide à SQLite

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

Le contrat de lecture

Références

Conclusion partielle

NuGet : Microsoft change son certificat de signature — faut-il modifier vos builds ?

Ce qui change exactement

Est-ce que je suis concerné ?

Un petit rappel sur les signatures NuGet

signatureValidationMode=require

Ce qu'il ne faut pas faire : remplacer l'ancienne empreinte

La méthode la plus simple avec le SDK .NET

Et dotnet nuget verify ?

Le vrai risque : le restore qui casse sans modification du code

Comment savoir rapidement si votre entreprise est concernée ?

CI/CD : GitHub Actions, Azure DevOps, Jenkins…

Faut-il installer le nouveau certificat dans le magasin Windows ?

Et si nous n'avons jamais configuré trustedSigners ?

Une bonne occasion de regarder enfin nos nuget.config

Ce que je ferais concrètement

En conclusion

Références

Spec Kit, SDD et la plomberie : quand l’industrialisation devient-elle contre-productive ?

SDD n’est pas Spec Kit

À quoi sert alors toute cette plomberie ?

La complexité traitée par Spec Kit n’est pas seulement celle du logiciel

Le parallèle avec GitHub est frappant

Le retour du coût de confiance

Ce n’est cependant pas un défaut intrinsèque de Spec Kit

Là se trouve le vrai paradoxe

Le bon niveau de SDD n’est donc pas universel

Sécurité des Agents IA : Pourquoi le Prompt ne remplacera JAMAIS vos autorisations (RBAC)

Le problème du « faux confort » du prompt

La solution : Le filtrage de catalogue & le double verrou

Découvrez la mise en pratique dans ma nouvelle vidéo !

`signatureValidationMode=require`

Et `dotnet nuget verify` ?

Le vrai risque : le `restore` qui casse sans modification du code

Et si nous n'avons jamais configuré `trustedSigners` ?

Une bonne occasion de regarder enfin nos `nuget.config`