L’avenir du développement passe forcément par le vibe coding ! Vraiment ?

Histoire de rester fidèle à mes mauvaises habitudes, je vais commencer cet article par la fin : non, je ne suis pas partisan du vibe coding. Cette méthode ne me semble pas destinée aux développeurs. Le simple fait que l’on ne s’intéresse au code, ne serait-ce que pour valider sa qualité, ou sa maintenabilité me répugne. Mais je suis développeur dans l’âme. Je suis donc friand de nouvelles solutions, et j’observe.

Note : Je publierai prochainement un article sur un usage du vibe coding qui me semble pertinent, et qui sort totalement du cadre que l’on nous présente habituellement.

Si on demande à Copilot, de parler du vibe coding, on peut obtenir ce résumé.

Vibe coding is an AI-assisted programming approach where users describe their software needs in simple language, and AI, particularly large language models (LLMs), generates the corresponding code. This technique allows individuals with little to no coding experience to create software by simply "following the vibes" of what they want, without needing to understand the underlying code. While it speeds up development, there are concerns regarding code quality, security, and maintainability. The term was coined by AI researcher Andrej Karpathy.

Le vibe coding, est là. Il faut vivre avec.

Bien avant le vibe coding

J’ai la chance de faire partie de ces développeurs qui ont débuté leur passion avant la généralisation d’Internet. Une époque merveilleuse, où chaque développeur prenait le temps d’installer la version la documentation fournie avec Visual Studio. Il fallait alors avoir le courage d’enchaîner les CD …

Une MSDN “hors ligne” qui prenait une place folle sur les PC. Cela devrait rappeler des souvenirs aux plus anciens.

À l’époque, il n’était pas facile d’échanger avec d’autres développeurs plus expérimentés. Il fallait donc prendre le temps de maitriser cette documentation afin d’en extraire les fragments de code salvateurs.

Un peu avant le vibe coding

Avec la généralisation d’Internet, la documentation est devenue plus accessible. Les sites de partages de code, et forums se sont multipliés (mon petit favori : VB France).

Même s’il est devenu plus facile d’échanger avec ses pairs, nombre de développeurs se sont alors mis à copier des bous de code, sans trop comprendre ce qu’ils faisaient.

Qui n’a jamais trouvé dans son application un pan entier de code tiré de Stack Overflow ? Ou un code rédigé par un collègue comportant des commentaires en anglais alors que celui-ci y est allergique ?

Faux clavier Stack Overflow + Coller

Aujourd’hui

Le vibe coding, est là avec ses nouveaux outils, et ses nouvelles pratiques. Même si je ne peux pas adhérer à l’idée d’utiliser un code que je ne prendrais pas le temps de comprendre, je pense qu’il faut rester ouvert.

Le vibe coding n’en est qu’à ses débuts. Son avenir en l’état me semble tout aussi incertain que celui des applications jetables que l’on pourrait générer avec. Je vois déjà les vagues de commerciaux d’ESN qui pense pouvoir vendre des prestations réalisées va le vibe coding, et qui dans quelques mois vont avoir du mal, à trouver des développeurs expérimentés pour faire la maintenance.

Conclusion

Gardons à l’esprit que personne n’a vraiment encore un grand recul sur cette approche.

Il s’agit d’une évolution du métier qu’il faut prendre en compte. Il y a des chances que de bonnes choses en ressortent… Même si je ne vois pas encore quoi.

Jérémy Jeanson

Comment passer rapidement un projet .net de Swagger à OpenAPI ?

Depuis .net 9, Microsoft permet de profiter simplement OpenAPI. Si de base je ne trouve pas OpenAPI extraordinaire (car en 2025, tout le monde ne semble toujours pas en accord avec ce standard), je dois avouer que j'apprécie beaucoup l'implémentation fournie par Microosft. Principalement pour sa légèreté, et sa gestion des metadata (Include OpenAPI metadata in an ASP.NET Core app | Microsoft Learn).

Si votre projet utilise encore Swagger, il est possible de passer très rapidement à OpenAPI. L'opération est simple et rapide.

Dans un premier temps, il suffit de remplacer la dépendance Swashbuckle.AspNetCore :


<PackageReference Include="Swashbuckle.AspNetCore" Version="8.1.1" />

Par Microsoft.AspNetCore.OpenApi :


<PackageReference Include="Microsoft.AspNetCore.OpenApi" Version="9.0.4" />

Pour finir, il n'y a plus qu'à remplacer ce code :


builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
  app.UseSwagger();
  app.UseSwaggerUI();
}

Par :


builder.Services.AddOpenApi();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (app.Environment.IsDevelopment())
{
  app.MapOpenApi();
}

Simple, non ?

Jérémy Jeanson

Vous n'arrivez pas toujours à compiler vos projets Wix Toolset via Azure Pipeline ?

Si vous utilisez Wix Toolset et Azure Pipeline, vous avez peut-être un petit problème. La configuration n'est pas forcément prise en compte.

Voici un petit exemple qui ne fonctionne pas correctement avec toutes les versions de Wix Toolset :


- task: DotNetCoreCLI@2
  displayName: 'Création du MSI'
  inputs:
    command: build
    projects: '**/Setup.wixproj'
    configuration: $(buildConfiguration)

Pour régler le problème, il suffit d'utiliser la propriété arguments de la tâche DotNetCoreCLI@2.


- task: DotNetCoreCLI@2
  displayName: 'Création du MSI'
  inputs:
    command: build
    projects: '**/Setup.wixproj'
    arguments: '--configuration $(buildConfiguration)'

Voilà, simple et efficace

Jérémy Jeanson

3 actions à entreprendre de suite si vous maintenez des applications .net Framework !

Nous avons beau être en 2025, nombre d’entreprises doivent maintenir des solutions .net Framework. Ce n’est pas une tare. J’en connais même qui maintiennent des applications écrites en VB6, et VBA.

Mais ce n’est pas parce que l’on dépend de .net Framework qu’il faut pour autant se sentir abandonné. Microsoft publie régulièrement des correctifs, et Visual Studio continue de supporter le Framework.

D’ailleurs, nombre de fonctionnalité de la CLI dotnet 9 sont utilisable avec .net Framework. Pour preuve, je vous propose aujourd’hui trois actions à réaliser au plus vite afin de mieux profiter de .net Framework, dotnet.exe, et ViSual Studio 2022 :

  • Migrer vos projets vers le format SDK.
  • Migrer vos fichiers sln, vers le format slnx.
  • Utiliser des packages nuget de .net 9.

Les deux premières vont améliorer les performances de Visual Studio, et faciliter les fusions (l’intelligence est aussi beaucoup plus réactive).

Note : la migration du format csprog / vbproj, peut être facilitée via le .net Upgrade Assistant. Celui-ci peut servir à changer que le format du projet. La migration de .net Framework à .net 8 ou 9, n’est pas forcée.

La dernière proposition quant à elle va vous permettre d’abandonner nombre d’API de .net Framework qui sont aujourd’hui un peu dépassées (sérialisation, cryptographie, authentification, etc.)

Jérémy Jeanson

Pourquoi, la migration des solutions vers le format SLNX n’est-elle pas possible pour tout le monde ?

Je constate avec beaucoup de plaisir qu’il y a un très fort engouement de la communauté .net autour du format de solution SLNX. Je ne reviendrai pas sur l’intérêt de ce nouveau format. Je crois que tout a déjà été dit sur le sujet. Il est évident que le SLNX va très vite s’imposer.

Cependant, il ne faudrait pas mettre la charrue avant les bœufs :

  • Oui, sur le plan technique, on peut tous adopter ce nouveau format.
  • Non, sur le plan pratique, tout le monde ne peut pas l’adopter de suite.

Vous allez me dire : “ C’est du Jérémy tout craché. Il ne peut pas dire oui sans dire non “. Vous n’aurez pas totalement tort. Dans le cas présent, ma réserve s’appuie sur les bases suivantes :

  • Le tooling utilisé par les développeurs doit être compatible.
  • Le tooling utilisé pour les builds doit être compatible.

Ces deux conditions doivent être remplies, et les outils doivent être déployés avant de commencer la migration. Faute de quoi, il y aura des problèmes.

Attention : ce n’est pas parce qu’un outil est compatible que l’opération se fera toute seule. Exemple : Visual Studio 17.13 supporte les SLNX, à condition d’activer la fonctionnalité via le menu des options (fonctionnalité qui est stable, mais toujours cataloguée en « preview » ).

Activation du support des SLNX dans Visual Studio

De plus, si vous avez à maintenir plusieurs versions majeures de vos applications, il faudra fusionner très vite les branches relatives à la migration pour éviter d’autres problèmes.

Jérémy Jeanson