Jérémy Jeanson's blog
chasseur de bugs depuis .net 1.0

Depuis le retour en force de l’IA, nombre de sujets sont « remis en perspective ». La tenue d’un blog, et la rédaction d’articles technique n’échappent pas à cela.

Attendez un instant je vais trop vite. Pourquoi parler d’un « retour en force » ?

L’IA, c’est tout beau, c’est tout nouveau, et c’est partout depuis 3 ans !

… et bien non.

Nous sommes nombreux à avoir joué avec l’IA avant les LLM, et la publication de Chat GPT (novembre 2022), et avant même la création d’Open AI (décembre 2015). Peut-être que les 7 ans d’écart entre 2015, et 2022, vous font un peu réfléchir. Si oui, c’est une bonne chose.

L’IA, ça n’est pas nouveau. Personnellement, j’ai réalisé mes premiers projets .net utilisant des service d’IA en 2015. Les vrais spécialistes de l’IA ont commencé bien avant l’an 2000.

Mais revenons à nos moutons. À force d’entendre parler de l’IA qui allait tout faire, et tous nous remplacer, je me suis véritablement interrogé sur l’utilité de ce blog. Quel intérêt avais-je à poursuivre cette aventure, si tout le monde demande à l’IA dès qu’il rencontre un problème technique. J’ai donc choisi de mettre ce projet en pause durant 2 mois :

• Passé le premier mois, je me suis demandé si le fait d’être autant impliqué dans ce blog, et les communautés de Dev ne me conduisait pas une forme de burn-out.
• Passer le second mois, rien, nada.
• Arrivé au troisième mois … oh ! Mais on s’était fixé dit 2 mois ?

Oui, je ne pensais pas prendre autant de temps pour moi. Mais je me suis rendu compte que je me faisais happer par le tourbillon de l’IA. J’expérimentais, je testais, j’utilisais, j’apprenais, je réapprenais. Je finissais par me demander si je gagnais du temps, ou si j’en perdais. En tant que développeur, c’était bien la première fois que le temps consacré à l’expérimentation ne se concluait pas par « un gain » (nouvelle compétence, nouvelle pratique, nouvel outil, etc.). Le temps consacré à l’IA telle qu’on en parle en 2025, c’était conclu pour moi en un retour à la case départ.

Oui, finalement il m’a fallu presque trois mois pour me dire que ce blog faisait partie du puzzle. Les IA ont besoin de contenu, et de personnes qui adoptent rapidement les technologies, car elles sont véritablement à la ramasse quand on parle de nouveautés. Aujourd’hui, peut-être même plus qu’hier, la communauté a besoin de développeurs qui partagent leur avis, et des retours expérience concrets sans langue de bois. Faire tout le reste sans tenir ce blog n’a plus trop de sens.

Je relance donc ce blog. Les contenus sont partis pour être très variés. Avec un peu d’IA, mais pas trop.

PS : Je pense que chacun doit avoir une posture vis-à-vis des IA. Moi, je ne suis pas un spécialiste de l’IA. Je suis un développeur qui sait l’implémenter dans ces réalisations.

La bonne pratique voudrait que tout code .net soit CLS Compliant. Aujourd'hui, on peut se demander pourquoi faire la remarque. Mais, je me suis rendu compte que nombre de développeurs ne savent pas ce que cela signifiait.

En une phrase : Un code CLS Compliant peut être appelé par un projet C#, F#, ou VB sans problèmes.

Quand le compilateur dit qu'un code n'est pas CLS Compliant, c'est donc qu'il y a un risque que votre librairie ne soit pas exploitable dans un autre projet. Attention : un autre projet peut utiliser votre code et compiler sans problèmes. Mais à l'exécution il peut y avoir des effets de bord.

Ex: une classe écrite en C# avec deux méthodes ayant le même nom, les mêmes arguments. Mais sur l'une d'elle, l'un des arguments est préfixé d'un "ref". VB ne sera pas en mesure de faire la différence entre ces deux méthodes.

Comme l'explique très bien la documentation, il y a beaucoup d'autres cas. Je présente celui-ci, car comme beaucoup de problèmes de codes non CLS Compliant, il y a là un problème de qualité de code. Cette manière de coder complexifie la lecture du code, et vos collègues, ou utilisateurs de votre librairie ne comprendront peut-être pas bien vos intentions.

Si vous n'utilisez un seul langage, un warning de type "not CLS Compliant" est à prendre comme un problème de qualité à traiter.

Il y aura malheureusement des cas où l'on doit utiliser des librairies, et des classes non CLS Compliant. Je pense par exemple à l'usage de très anciens interops Office.

Dans ces cas, là il y a une approche très simple à suivre :

• Ne pas utiliser ces types comme arguments de vos méthodes publiques.
• Créer des classes "passe-plat" qui seront CLS Compliant, et qui porteront les propriétés dont vous avez besoin pour créer en interne l'objet non CLS Compliant.

Si cela n'est pas possible, il faut marquer la classe avec l'attribut suivant (ceci est le dernier recours, on est d'accord?):

[CLSCompliant(false)]

Mais surtout, il ne faut pas utiliser cet attribut au niveau de l'assembly. Si vous l'avez dans votre projet, passez-le temporairement à true pour observer les dégâts, et planifier leur remédiation.

[assembly: CLSCompliant(true)]

Cet attribut mis à false, est là pour cacher la misère. Il finira toujours par propager les problèmes.

J’ai choisi de vous partager aujourd’hui une déconvenue qui m’a fait réfléchir. Lors d’une présentation d’Azure DevOps Server (usages pro, et possibilités), il m’a été reproché de promouvoir / défendre le produit.

J’ai été décontenancé par la remarque, et me suis rendu compte que ma présentation pouvait effectivement être prise comme telle.

À être trop enthousiaste vis-à-vis d’un outil peut donner une mauvaise idée de nos intentions. Quand on aime le DevOps, créer de la confusion, ce n’est pas « foufou » (oui, je le permets une expression de vieux). « Sacrebleu », briser le mur la confusion, c’est DevOps !!!

Moralité

Attention à sa posture quand on parle d’outils que l’on aime utiliser.

Conclusion ++

Jusqu’ici, je gardais toujours ma liste avantages / inconvénients pour déclencher la conversation off qu’il y a toujours en fin de réunion. Maintenant je ferai une slide à l’ancienne avec le menu, et un gros titre « inconvénients ».

Et vous

Ce genre de méprise vous est-il déjà arrivé ?

PS : Oui je vais rédiger un article au sujet de ce qui est pour moi LE très gros inconvénient d’Azure DevOps Server.

J'ai le plaisir de vous annoncer que Microsoft m'a décerné un nouveau MVP Award. Cette année dans la catégorie DevOps. Ce qui m'emplit encore davantage de fierté.

Après avoir été reconnu durant 15 ans pour mes travaux sur .net, et ses outils, être récompensé pour un autre aspect du métier est très agréable.

Merci à Microsoft pour cette reconnaissance, et merci à tous ceux qui prennent le temps de me lire.

Un remerciement tout particulier pour celles, et ceux qui prennent le temps de m'envoyer un petit message pour le soutenir, ou entamer la discussion sur .net et DevOps. Mes derniers articles m'ont permis d'avoir de nombreux retours. J'en suis très heureux. Je vais donc continuer sur cette lancée ;)

Suite à mon précédent article, il m’a été demandé si j’allais me mettre à critiquer les méthodes agiles. Désolé, il n’en est rien. Je ne renierai, et ne critiquerai pas les méthodes agiles.

Ma raison est très simple :

J’ai eu la chance de faire de l’agilité sans le savoir, à une époque ou personne ne parlait d’agilité en France. Par la suite, un collègue m’a fait découvrir l’Extreme Programming (XP). Ce fut une vraie révélation. Depuis, l’amélioration continue est devenue ma façon de vivre le développement logiciel.

Donc non, je ne peux pas critiquer l’agilité. Je reconnais qu’il y a une véritable mode à ce sujet depuis quelques années. Une sorte de tendance à suivre... (ou pas).

Pourquoi ?

Si vous êtes attentifs, vous vous rendrez compte que nombre de détracteurs de l’agilité vantent les métrites du DevOps, ou du DevSecOps, tout en reniant Scrum, et/ou le manifeste agile.

Vous vous dites peut-être que je tends à faire une grosse généralité, et que je mélange tout. Très bien, vous êtes attentifs, et comprenez le sujet. C’est exactement là que je souhaite vous mener.

Au sujet du manifeste agile :

j'avoue que je ne suis pas fan. À mon sens, ce n'est pas utile. Il s'agit d'une déclaration d'intention à laquelle tout le monde ne doit pas être tenu. Chaque équipe doit être libre, et doit faire évoluer sa méthode en fonction de ses propres objectifs, et de sa maturité.

L’agilité : « comptable désignée » ?

Avec le temps, l’agilité est devenue un gros four tout purement commercial pour certains. Cela va de l’ESN, aux coachs agiles, en passant par les AMOE, AMOA, et chefs de projets convertis à la hâte en Scrum Masters.

Oui, je mets les coachs agiles dans ce panier de crabes. Tous ne sont pas concernés pour autant. Je désigne ici le coach qui travaille 100% de son temps pour une même équipe depuis des années… Pourquoi cette équipe ne vole-t-elle toujours pas de ses propres ailes ?

L’agilité a été un beau business. Mais certains clients se sont rendu compte que les promesses n’étaient pas au rendez-vous.

Par chance, DevOps est arrivé (« sans se presser, le grand Zorro… »).

Il fallait donc changer de méthode, et blâmer l’agilité. Sans pour autant se rendre compte que l’agilité était une composante de DevOps. Mais ceci est un autre sujet.

Conclusion

Je pense donc que le problème est lié aux personnes qui ont fait de l’agilité leur business, mais qui n’ont pas su adhérer aux méthodes.

Et la suite ?

Peut-être, pensez-vous que DevSecOps est arrivé et qu’il faut chasser DevOps. Désolé, je ne critiquerai pas DevOps au profit de DevSecOps. J’ai toujours considéré que la sécurisation de la chaine de production, et livraison faisait partie du package. Pour moi, DevSecOps est un nouveau terme marketing. Mais s’il peut faire comprendre que la sécurité doit être incluse by design dans le DevOps, je ne peux pas non plus le critiquer.

Comme l’agilité, DevOps n’est pas figé, et s’inscrit dans une logique d’amélioration continue.

Exemple :

La disparition progressive des Personnel Access Token dans Azure DevOps, n’est pas « une nouveauté DevSecOps ». C’est une évolution qui s’inscrit parfaitement dans la logique Zero Trust que nous devrions tous adopter. En 2025, combien de ces tokens finissent encore dans des repos Git ?