Dans mes applications, le dialogue entre le code et la base de données MySQL passe par deux briques : Entity Framework Core, l'outil officiel de Microsoft, et Pomelo, le composant communautaire qui fait le pont entre cet outil et MySQL spécifiquement. EF Core ne sait pas parler à MySQL tout seul ; c'est Pomelo qui traduit.
Cette dépendance a une conséquence que j'assume comme une règle : je fige volontairement EF Core à la version 9, alors que la version 10 est disponible. Ce n'est pas de la frilosité, c'est la conclusion de plusieurs incidents concrets. Voici le raisonnement, et les deux pièges qui le justifient.
Le composant le plus lent commande la cadence
Pomelo est maintenu par la communauté, et il suit les sorties de Microsoft avec un décalage structurel d'environ deux versions. Quand Microsoft publie EF Core 10, Pomelo n'a pas encore de version stable compatible. Tant que ce rattrapage n'a pas eu lieu, monter EF Core revient à faire reposer la couche d'accès aux données sur un composant en chantier.
La règle que j'applique est simple : dans une chaîne de dépendances, c'est le maillon le plus lent à se mettre à jour qui fixe le rythme, pas le plus rapide. Adopter la dernière version de l'outil officiel sur un traducteur qui ne la supporte pas encore, c'est gagner un numéro de version et perdre la stabilité. Pour un site personnel, le pari est tolérable. Pour la base de données d'un client, non.
Deux pièges précis illustrent pourquoi le décalage n'est pas théorique.
Piège 1 : la fonctionnalité officielle qui n'existe pas chez Pomelo
EF Core propose, depuis plusieurs versions, une manière standard de ranger une donnée structurée (une liste, un objet) dans une seule colonne au format JSON. C'est documenté, c'est l'approche officielle, et la documentation générale vous invite à l'utiliser.
Sauf que Pomelo ne l'implémente pas. La fonctionnalité officielle existe sur le papier mais pas dans le traducteur MySQL : à la première tentative, l'application refuse de démarrer avec un message explicite indiquant que ce support n'est pas disponible. Le piège est pédagogique autant que technique : on suit la documentation de référence, et ça casse, parce que la documentation décrit l'outil générique sans préciser que ce traducteur précis fait autrement.
La parade consiste à passer par un mécanisme plus manuel pour obtenir le même résultat (une colonne JSON parfaitement fonctionnelle), encapsulé proprement pour rester lisible. Le coût est une poignée de lignes une fois pour toutes ; le bénéfice est de ne pas ajouter de nouvelles dépendances juste pour contourner le manque.
Piège 2 : le tri qui diverge entre les tests et la production
Celui-ci est plus sournois, car il ne provoque aucune erreur. Il produit simplement un résultat faux, et seulement en production.
Le contexte : pour qu'une donnée soit lisible directement dans la base, je stocke certaines catégories sous forme de texte plutôt que de code numérique. Avantage, une requête manuelle reste compréhensible. Inconvénient découvert à l'usage : quand on trie sur cette colonne, le résultat dépend de l'environnement. Dans la base utilisée pour les tests automatisés, le tri respecte l'ordre logique voulu (l'ordre dans lequel les catégories ont été pensées). Dans MySQL en production, le tri se fait par ordre alphabétique du texte. Deux ordres différents pour le même code.
Le danger tient à ce décalage : les tests passent au vert, l'application semble correcte, et le tri est pourtant faux une fois en production. Un regroupement par thème qui sortait dans le bon ordre en test sortait mélangé chez l'utilisateur. La parade consiste à effectuer ce tri précis dans le code plutôt que de le déléguer à la base, ce qui garantit le même résultat partout. Et la leçon générale dépasse ce cas : un test vert ne prouve pas qu'un comportement est correct, seulement qu'il est correct dans l'environnement de test. Quand cet environnement diffère de la production, il faut le savoir et le compenser.
Ce que ça dit de ma façon de travailler
Caper une version, contourner une fonctionnalité absente, se méfier d'un test trop confiant : ce sont des décisions sans gloire, invisibles sur une démonstration. Elles font pourtant toute la différence entre une application qui tient deux semaines et une application qui tient trois ans sur l'infrastructure d'un client, sans moi à proximité pour éteindre les incendies.
C'est aussi pour ça que je documente ces choix et que je les livre avec le code. Le jour où vous, ou un autre prestataire, reprenez l'application, vous trouvez non seulement le « quoi » mais le « pourquoi » : pourquoi cette version est figée, pourquoi ce contournement existe. C'est la différence entre hériter d'un outil et hériter d'une énigme. Si vous avez une application dont personne ne sait plus expliquer les choix, c'est typiquement ce qu'un audit de dette technique remet à plat.