Dossier d'étude — juin 2026

Sortir de WinDev / PC Soft : quel langage, quelle stack en 2026 ?

Étude multi-agents vérifiée par confrontation contradictoire — desktop fenêtré, services Windows, daemons Linux, avec réutilisation des compétences web. Préparée pour Michael & Serge.

📅 11 juin 2026 🤖 106 agents de recherche 📚 24 sources, 110 affirmations extraites ⚖️ 25 vérifiées · 23 confirmées · 2 réfutées

1Comment cette étude a été menée

Ce dossier n'est pas l'avis d'une seule IA : c'est le produit d'une recherche structurée où chaque affirmation chiffrée a dû survivre à une vérification contradictoire avant d'apparaître ici.

  1. Décomposition — la question a été découpée en 5 angles d'attaque : panorama des frameworks GUI desktop 2026 · popularité réelle (enquêtes récentes) · services Windows & daemons Linux en langage compilé · retours de praticiens ayant migré depuis un RAD (WinDev, Delphi) · qualité de l'assistance IA par langage.
  2. Recherche parallèle — 5 agents de recherche web indépendants, un par angle.
  3. Lecture des sources — 24 sources lues intégralement, 110 affirmations factuelles et falsifiables extraites.
  4. Vérification contradictoire — les 25 affirmations les plus structurantes ont chacune été soumises à 3 vérificateurs indépendants chargés de les réfuter (accès direct aux sources primaires : API GitHub, pages d'enquêtes, docs officielles). Une affirmation réfutée par 2 voix sur 3 est éliminée.
  5. Synthèse — 23 affirmations confirmées (la plupart à 3 voix contre 0), 2 réfutées et écartées — elles sont documentées en section 9 par transparence.
106agents mobilisés
5angles de recherche
24sources lues
110affirmations extraites
23 / 25vérifiées confirmées
2réfutées & écartées

2Le cahier des charges

Les critères posés au départ, tels qu'énoncés. L'un d'eux est éliminatoire — c'est lui qui fait basculer le classement final (voir section 8).

CritèreNatureDétail
Pas (fortement) orienté objetÉliminatoireCritère personnel ferme de Serge — pas de POO imposée par le langage.
Langage compiléImpératifBinaire déployable simple, sans runtime à installer chez le client.
Desktop fenêtré Windows + LinuxImpératifApplications avec fenêtres (au pluriel — le multi-fenêtres compte).
Services Windows + daemons LinuxImpératifUne seule base de code pour les deux mondes.
Lisible / maintenableImportant« Un langage qui ne fait pas vomir » et qu'on sait relire des années après.
Écosystème stableImportantPas de churn type frameworks JS — le syndrome « idweaver » à éviter.
Bonne assistance IAImportantCritère 2026 : Claude/Copilot écrivent le gros du code, le dev relit.
Compétences mutualisées avec le webSouhaitéIdéalement, la même base de savoir-faire pour le web et le desktop.

3Les chiffres clés vérifiés

Toutes les données ci-dessous ont été confirmées 3 voix contre 0 sur sources primaires (pages d'enquêtes vérifiées verbatim, API GitHub interrogée le 11/06/2026).

Popularité réelle des langages — Stack Overflow 2025 (49 062 répondants)

% des développeurs ayant « travaillé intensivement avec » durant l'année écoulée. Dernière édition disponible en juin 2026.

LangagePart d'usageLecture
C# 27,8 %1,7× la base de Go, 1,9× celle de Rust
C++ 23,5 %Massif mais hors cahier des charges (complexité)
C 22,0 %Idem
Go 16,4 %Base solide + plus forte dynamique (cf. ci-dessous)
Rust 14,8 %« Most admired » à 72 %, +2 pts/an
Dart (Flutter) 5,9 %Risque de niche modéré
Delphi (proxy Lazarus/FreePascal) 2,5 %Risque de niche élevé
Zig 2,1 %Trop jeune / trop niche

Dynamique d'adoption — JetBrains 2025 (24 534 répondants) & GitHub Octoverse 2025

  • Go est le langage n°1 que les développeurs veulent adopter (11 % d'intention), Rust n°2 (10 %). Croissance qualifiée de « lente et régulière » sur 5 ans — exactement le profil anti-churn recherché — pendant que PHP, Ruby et Objective-C déclinent.
  • Go : 2,2 millions de développeurs professionnels en langage principal — le double d'il y a 5 ans (extrapolation JetBrains, éditeur de GoLand — intérêt commercial signalé).
  • C# : n°5 des langages sur GitHub en 2025, +22 % de contributeurs sur un an (~136 735 contributeurs gagnés), porté par le cloud, le desktop et le jeu vidéo. La pérennité d'écosystème la mieux établie des trois finalistes.

Empreinte binaire — application vide, Windows x64 (benchmark reproductible, MAJ juin 2026)

StackTailleNote
Neutralino ~1 MoNon retenu (écosystème trop petit)
Tauri (Rust) ~3 MoWebView2 système non compté
Wails (Go) ~11 MoWebView2 système non compté
Flutter ~27 MoMoteur de rendu embarqué
Electron ~370 MoDossier décompressé ; installeur ~85-100 Mo. Écart réel ~10-30× : disqualifiant.

Communautés des frameworks desktop — stars GitHub (API interrogée le 11/06/2026)

FrameworkStarsLecture
Flutter 176 880Couvre mobile + web + desktop, pas le desktop seul
Electron 121 598L'historique, en perte de vitesse relative
Tauri 107 744A quasi rejoint Electron (~89 %)
Wails 34 750Communauté ~3× plus petite que Tauri

4Les concurrents, un par un

Forces et faiblesses de chaque option, sur la base des affirmations vérifiées. Les options absentes des données vérifiées sont signalées comme telles plutôt que notées au doigt mouillé.

Go

Conforme « pas POO » Compilé GUI : point faible

Langage de Google (2009), pensé pour la simplicité : structs + fonctions + interfaces, pas de classes ni d'héritage. Le langage des daemons modernes (Docker, Kubernetes, Caddy sont écrits en Go).

Forces vérifiées

  • Seul langage majeur du panel non orienté objet — le critère éliminatoire est respecté nativement.
  • Momentum n°1 du marché : langage le plus désiré (JetBrains 2025), 2,2 M de devs pro, ×2 en 5 ans.
  • Services/daemons : kardianos/service (4,8k stars, utilisé par 1 431 packages) = une API unique pour service Windows (XP+), systemd/Upstart/SysV et launchd, avec détection terminal-vs-service.
  • Binaire statique unique, cross-compilation triviale (GOOS=linux go build depuis Windows).
  • Promesse de compatibilité Go 1 tenue depuis 2012 — anti-churn au niveau langage.
  • + de 70 % des devs Go utilisent un assistant IA (JetBrains 2025, corroboré par le Go Developer Survey 2025 : 53 % quotidien + 18 % occasionnel).

Faiblesses vérifiées

  • Aucun framework GUI à la fois mature ET stable en juin 2026 — la faiblesse unique mais déterminante (détail section 5).
  • Wails v2 stable mais mono-fenêtre et API en fin de vie ; v3 multi-fenêtres mais en alpha (alpha.99 du 10/06/2026) avec rupture d'API complète.
  • kardianos/service : maintenance lente (~11 mois sans commit) et bugs documentés sur cas exotiques (Dependencies non implémenté Linux/launchd).
  • Fyne et Gio (GUI pur Go) : pas assez de données solides pour être départagés — angle mort de l'étude, à valider par un test pratique.
Verdict : le meilleur alignement avec le cahier des charges tel qu'énoncé. Backend, services et daemons : sans risque dès aujourd'hui. Desktop fenêtré : le maillon faible, problème de timing (Wails v3 pas encore stable) plus que de nature.

C# / .NET (+ Avalonia)

POO — critère éliminatoire Stack le plus complet

Le mastodonte Microsoft. Avec Avalonia (GUI cross-platform) et Native AOT (compilation en binaire natif autonome), .NET couvre désormais toute la chaîne demandée — sauf un détail : c'est de la POO de bout en bout.

Forces vérifiées

  • Popularité écrasante : 27,8 % (SO 2025), n°5 GitHub à +22 %/an — pérennité d'écosystème la mieux établie du panel.
  • Avalonia 12 (avril 2026) : GUI cross-platform mûr et activement maintenu — Windows, macOS, Linux (+ iOS, Android, WebAssembly), ~17,4 M de téléchargements NuGet, télémétrie éditeur 122 M builds / 2,1 M projets.
  • Services/daemons première classe : BackgroundService + UseWindowsService() / UseSystemd() empilables dans le même code (chacun inactif hors de son OS).
  • Native AOT (.NET 9+) : binaire natif autonome sans runtime à installer, Windows (x64/Arm64/x86) et Linux (x64/Arm64/Arm).
  • Corpus d'entraînement IA énorme → assistance maximale.

Faiblesses vérifiées

  • Orienté objet partout : tout est classe, tout hérite d'object ; Avalonia = XAML + MVVM + hiérarchies de classes. Le C# moderne (records, top-level statements) allège la syntaxe, pas la culture.
  • Native AOT ne supporte ni WinForms ni WPF → la voie GUI compatible binaire autonome est Avalonia (ou WinUI3), pas les frameworks Windows historiques.
  • Limites AOT : un binaire par plateforme cible, pas de Reflection.Emit ni chargement dynamique, binaire Linux lié à la distro de build ou plus récente.
  • Avalonia 12 abandonne Tizen, Direct2D1 et netstandard2.0 (impact faible pour ce besoin).
  • Dépendance à la roadmap Microsoft (vendor lock-in modéré).
Verdict : objectivement le stack le plus complet et le plus sûr de 2026 — mais il échoue sur le critère éliminatoire « pas POO ». À garder au dossier comme le choix rationnel si ce critère est levé, pas comme vainqueur par défaut. C'est un arbitrage humain, pas technique (voir section 8).

Rust (+ Tauri)

Pas de POO classique Courbe d'apprentissage rude

Le langage le plus admiré du marché (72 % « most admired », SO 2025), binaires minuscules, sécurité mémoire. Tauri est son framework desktop vedette, quasi au niveau d'Electron en communauté.

Forces vérifiées

  • Tauri v2 stable et production-ready (107,7k stars, ~89 % d'Electron) — binaires ~3 Mo, les plus petits du panel.
  • Momentum n°2 derrière Go (JetBrains 2025), +2 pts d'usage par an.
  • Pas d'héritage de classes (traits + structs) — compatible avec l'esprit « pas POO ».
  • Crate service-manager v0.11.0 (février 2026, ~19,4k téléchargements/mois) : abstraction de 6 gestionnaires de services.

Faiblesses vérifiées

  • Courbe d'apprentissage la plus raide du panel (ownership, borrow checker, lifetimes) — à l'opposé de l'esprit RAD.
  • Affirmation « API services uniforme sans plomberie par OS » réfutée 0-3 : pour un service Windows natif, le binaire doit implémenter lui-même le dispatcher SCM (crate windows-service séparée). Plus de friction que Go ou C#.
  • Lisibilité : difficile de prétendre que Rust « ne fait pas vomir » un ex-WinDev — le critère lisible/maintenable est mal servi.
Verdict : techniquement au sommet, humainement le plus coûteux. Pertinent si la performance extrême ou la sécurité mémoire devenaient des critères — ce n'est pas le cas ici.

Lazarus / FreePascal

Niche : 2,5 % Le plus proche de l'esprit RAD

Forces

  • RAD visuel avec éditeur de fenêtres — philosophiquement le plus proche de WinDev/Delphi.
  • Compilé natif, multi-plateforme, projet vivant (v4.6 récente, forum actif : ~560 000 posts, 22 000 membres).
  • Pascal : familier pour qui en a fait, POO présente mais non imposée au même degré que C#.

Faiblesses

  • Risque de niche quantifié : 2,5 % d'usage (proxy Delphi, SO 2025) — recrutement et entraide quasi impossibles.
  • Assistance IA faible : corpus Pascal/LCL marginal dans l'entraînement des modèles — on se prive du levier principal de 2026.
  • Sortir d'une niche propriétaire (PC Soft) pour entrer dans une niche communautaire : le problème de fond reste.
Verdict : option confort défendable pour un développeur seul, sur de l'interne, en fin de carrière. Pas un choix d'avenir pour une base de code à faire vivre.

Python

Non compilé À garder comme outil d'appoint

Forces

  • Ubiquitaire, immense écosystème, excellente assistance IA.
  • Imbattable pour scripts, automatisation, data, prototypage.

Faiblesses

  • Interprété : échoue sur le critère « binaire déployable simple » (packaging PyInstaller lourd et fragile).
  • Services Windows bricolés (pywin32/NSSM), pas de binaire autonome propre.
  • Fortement POO dans ses frameworks, typage optionnel — le virage industrie va vers les langages typés (cf. section 7).
Verdict : le doute exprimé au départ (« pas sûr qu'on puisse faire un service avec ça ») est confirmé en substance. Couteau suisse, pas langage produit.

Electron / Node.js

Disqualifié : ~370 Mo

Le vétéran du web-to-desktop (VS Code, Slack, Discord). Mais ~370 Mo décompressés pour une application vide (installeur ~85-100 Mo) contre 3-11 Mo pour Tauri/Wails — un écart de 10 à 30× qui disqualifie sur le critère « binaire déployable simple ». Pas compilé (JavaScript embarqué dans un Chromium complet). Sa communauté reste massive (121,6k stars) mais Tauri l'a quasi rejointe.

Verdict : hors course sur les critères posés. Son intérêt historique (réutiliser les compétences web) est repris par Tauri et Wails pour une fraction du poids.

Flutter / Dart

Niche relative : Dart 5,9 %

La plus grosse communauté du panel (176,9k stars — mais elles couvrent surtout le mobile). Binaires ~27 Mo, langage Dart orienté objet, priorité produit clairement mobile : le desktop y est un citoyen de seconde zone. Échoue sur « pas POO » et sur la mutualisation des compétences web (Dart ≠ HTML/CSS/JS).

Verdict : pertinent si le mobile devenait le besoin principal. Pas ici.

Zig · V · C/C++ (Qt) · .NET MAUI

Écartés ou non départagés
  • Zig — 2,1 % d'usage (SO 2025), pas encore en version 1.0 : trop jeune pour bâtir dessus.
  • V — aucune donnée fiable n'a survécu à la vérification ; communauté confidentielle.
  • C/C++ + Qt — techniquement capable de tout, mais complexité élevée, licence Qt commerciale piégeuse, et aucune affirmation vérifiée n'a pu le départager dans cette étude (angle mort assumé).
  • .NET MAUIne supporte pas Linux desktop : éliminé d'office sur le périmètre Windows + Linux. C'est Avalonia qui porte la voie C# cross-platform.

5Le nerf de la guerre : les frameworks GUI

C'est ici que le match se joue réellement. Les trois langages finalistes savent tous faire des services et des daemons — c'est sur le desktop fenêtré qu'ils se séparent.

FrameworkLangageÉtat (11/06/2026)Multi-fenêtresVerdict
Avalonia 12C# Stable, sortie 04/2026 ✅ Oui Le seul GUI du panel à la fois mûr, stable et activement maintenu
Wails v2Go Stable mais API en fin de vie Mono-fenêtre Utilisable aujourd'hui, mais on bâtit sur une API condamnée
Wails v3Go Alpha (alpha.99 du 10/06/2026) ✅ Oui (enfin) 103 tags, tous alpha ; rupture d'API complète vs v2 ; pas de date de stable
Tauri v2Rust Stable depuis 10/2024 ✅ Oui Mûr, grosse communauté — mais backend Rust
Fyne / GioGo Non départagés ✅ / ✅ GUI pur Go sans webview — pas assez de preuves vérifiées : à tester soi-même
egui / SlintRust Non départagés Idem : angle mort de l'étude
WinForms / WPFC# Windows uniquement Pas de Linux + incompatibles Native AOT → écartés
⚠️ La découverte la plus structurante de l'étude Le critère demande des « applications desktop avec fenêtres ». Or Wails v2 — la voie Go stable — est mono-fenêtre ; le multi-fenêtres n'arrive qu'avec la v3, toujours en alpha après 103 versions (alpha.99 datée de la veille de cette étude), avec une rupture d'API complète (migration estimée 1-4 h par l'équipe elle-même, API déclarative remplacée par une API procédurale). Se lancer sur Wails aujourd'hui = choisir entre une API condamnée et une API instable. C'est précisément le churn de framework que le cahier des charges veut éviter — et la démonstration que la stabilité d'un langage ne garantit pas celle de ses frameworks GUI.

6Services Windows & daemons Linux

Le besoin « une base de code → service Windows + daemon Linux » est couvert par les trois finalistes, avec des niveaux de confort différents — tous vérifiés sur sources primaires.

StackMécanismeConfortRéserves vérifiées
C# / .NET BackgroundService + UseWindowsService() et UseSystemd() empilés dans le même code — chacun est sans effet hors de son OS. Successeur officiel Microsoft des Windows Services du Framework. Maximal Aucune réserve significative. Native AOT livre le binaire autonome.
Go kardianos/service : installe/désinstalle/démarre/arrête et exécute le binaire comme service natif — Windows XP+, Linux (systemd/Upstart/SysV), macOS launchd — API unique + détection terminal-vs-service (service.Interactive()). Très bon Maintenance lente (~11 mois sans commit, dernier push 07/2025) ; Dependencies non implémenté sur Linux/launchd ; 4,8k stars, 1 431 packages dépendants = battle-tested malgré tout.
Rust Crate service-manager v0.11.0 (02/2026) : abstrait 6 gestionnaires (sc.exe, WinSW, systemd, OpenRC, launchd, rc.d). Incomplet Claim « pas de plomberie par OS » réfutée 0-3 : pour un service Windows natif, il faut implémenter soi-même le dispatcher SCM via la crate séparée windows-service. Plus de travail manuel que Go ou C#.

7Le facteur 2026 : l'assistance IA

Critère absent des comparatifs d'il y a cinq ans, central aujourd'hui : le gros du code est écrit par l'IA, le développeur relit. Ce que disent les données vérifiées :

  • Le marché bascule vers les langages typés à cause de l'IA. GitHub Octoverse 2025 attribue explicitement la montée de TypeScript (devenu n°1) au glissement vers les langages typés « qui rendent le codage assisté par agents plus fiable en production ». Étude citée : ~94 % des erreurs de compilation générées par les LLM sont des échecs de vérification de type — un compilateur strict attrape ce que Python ou JavaScript laissent passer en production. Mécanisme qui joue à plein pour Go, Rust et C#. (GitHub est vendeur de Copilot — conflit d'intérêt léger signalé.)
  • Adoption massive côté Go : plus de 70 % des développeurs Go utilisent au moins un assistant IA (JetBrains 2025 ; corroboré indépendamment par le Go Developer Survey 2025 : 53 % quotidien + 18 % occasionnel). JetBrains attribue la « LLM-friendliness » de Go à sa simplicité syntaxique.
  • Nuance honnête : l'adoption ne prouve pas la qualité — le même Go Survey relève que le problème n°1 cité est « le code généré ne fonctionne pas » (53 %), et la satisfaction globale des outils IA n'est que de 55 %. L'IA accélère, elle ne dispense pas de relire.
  • Par corpus d'entraînement : C# et Go sont massivement représentés (assistance excellente), Rust bien couvert, Pascal/LCL marginal — un handicap structurel pour Lazarus, impossible à compenser.
  • Question restée ouverte : la qualité comparée de l'IA par framework GUI (Avalonia/XAML vs Wails vs Tauri) n'a pas pu être tranchée par des preuves — seule l'adoption par langage est mesurée.

8Le classement — et pourquoi il bascule

L'étude produit deux classements, et l'écart entre les deux est la vraie leçon de ce dossier. Le premier note sur les données brutes ; le second applique le cahier des charges tel qu'énoncé, avec son critère éliminatoire.

📊 Classement « données brutes »

Popularité, maturité GUI, complétude de la chaîne — sans pondération des critères personnels.

1
C#/.NET + AvaloniaSeul stack cumulant popularité massive, GUI mûr et stable, services first-class, binaire AOT autonome, IA maximale.
2
GoMomentum n°1, services/daemons excellents, binaires légers — freiné uniquement par l'absence de GUI mature ET stable.
3
Rust + TauriBinaires au sommet, Tauri mûr — mais courbe brutale et plomberie services Windows incomplète.
4+
Electron · Flutter · Lazarus · ZigDisqualifié (poids) · niches quantifiées (5,9 % / 2,5 % / 2,1 %).

🎯 Classement « cahier des charges appliqué »

Le critère « pas POO » est éliminatoire — il a été posé comme tel, il se traite comme tel.

1
GoSeul candidat conjuguant « pas POO » et écosystème majeur. Sa faiblesse GUI est un problème de timing, pas de nature.
C#/.NET + Avalonia — éliminéPOO de bout en bout (langage ET écosystème XAML/MVVM). Reste documenté comme « le choix rationnel si le critère est levé ».
2
Rust + TauriPas de POO classique, mais sacrifie « lisible / courbe douce » — l'esprit RAD en souffre.
3
Lazarus/FreePascalSi et seulement si : développeur seul, interne, horizon court. Niche + IA faible sinon.
💡 Le pourquoi du comment — l'explication de la bascule Les agents de recherche ont classé sur les données mesurables : à ce jeu, C# gagne légitimement (1,7× la base d'usage de Go, le seul GUI cross-platform mûr du marché, la chaîne services + AOT complète). Mais ils ont traité « pas fortement orienté objet » comme une question ouverte — « le C# moderne suffit-il à neutraliser l'objection ? » — au lieu de l'appliquer comme le critère éliminatoire qu'il est. C'est le biais classique du classement pondéré : un critère dur noyé dans une moyenne. Une fois le cahier des charges appliqué tel qu'énoncé, Go passe en tête — et C# reste au dossier, honnêtement documenté, comme l'option qui domine si l'on accepte d'en payer le prix culturel. La décision finale est un arbitrage humain : qu'est-ce qui pèse le plus, le confort d'un GUI mûr aujourd'hui (Avalonia) ou le refus de la POO ? Personne d'autre que l'intéressé ne peut trancher ça.

9Transparence : réfutations, limites, questions ouvertes

Une étude honnête montre aussi ce qu'elle a écarté et ce qu'elle n'a pas réussi à prouver.

Les 2 affirmations réfutées par les vérificateurs

Réfutée 1-2« Tauri et Wails offrent tous deux un support officiel Vite/React/Vue/Angular/Svelte, garantissant la réutilisation directe des compétences web. »
La promesse « mêmes compétences que le web » est plausible dans les grandes lignes mais n'a pas survécu à la vérification dans le détail des tooling officiels. À valider en pratique avant d'en faire un argument décisif.

Réfutée 0-3« La crate Rust service-manager offre une API uniforme sans plomberie spécifique par OS. »
Faux : avec le backend sc.exe, le binaire doit implémenter lui-même le dispatcher SCM Windows (crate windows-service séparée). Rust demande plus de travail manuel que Go ou C# pour les services Windows natifs.

Limites assumées de l'étude

  • Angles morts : Fyne, Gio (GUI pur Go), egui, Slint (Rust natif), Qt/C++, le packaging desktop Python, V et le détail MAUI/WinForms/WPF n'ont pas pu être départagés par des preuves vérifiées — le classement les omet plutôt que de les noter sans données. La piste Fyne, en particulier, reste ouverte côté Go.
  • Stabilité langage ≠ stabilité framework : les preuves de non-churn portent sur Go/Rust/C# en tant que langages ; Wails v2→v3 démontre précisément du churn côté framework.
  • Aucune donnée de performance runtime (CPU/RAM en charge) n'a survécu à la vérification — seules les tailles de binaires sont chiffrées.
  • Sensibilité temporelle : Wails v3 (alpha.99 au 10/06/2026, cadence hebdomadaire) peut passer beta à tout moment ; les enquêtes citées (SO, JetBrains, Octoverse) datent de mi/fin 2025, éditions 2026 non parues.
  • Conflits d'intérêts mineurs signalés : télémétrie Avalonia auto-déclarée par l'éditeur, GitHub vendeur de Copilot, JetBrains vendeur de GoLand. Aucun n'invalide les ordres de grandeur (recoupés sur sources indépendantes quand c'était possible).
  • Lazarus/FreePascal n'est mesuré que via le proxy Delphi dans SO 2025 (non listé séparément).

Questions restées ouvertes

  • Maturité réelle et stabilité d'API de Fyne et Gio (Go) et egui/Slint (Rust) en 2026 — ils répondraient au besoin sans dépendance webview.
  • Qualité comparée du code généré par l'IA sur Avalonia/XAML vs Wails/Go vs Tauri/Rust spécifiquement.
  • Quand Wails v3 atteindra-t-il la beta puis la stable, et l'API actuelle sera-t-elle gelée d'ici là ?
  • Le critère « pas POO » disqualifie-t-il C# en pratique pour ces développeurs, ou le style C# moderne suffit-il à le neutraliser ? Question de fit humain, non tranchable par les sources — seulement par l'essai.

10Recommandation pour se lancer aujourd'hui

✅ Voie principale recommandée : Go Backend, services Windows, daemons Linux : se lancer dès maintenant, sans risque — c'est le terrain naturel de Go, le critère « pas POO » est respecté nativement, le binaire statique cross-compilé règle le déploiement, et l'écosystème langage est le plus dynamique du marché. Pour le desktop fenêtré : tester Fyne (GUI pur Go, une seule couche, multi-fenêtres — à valider soi-même, angle mort de l'étude) et surveiller Wails v3 (l'API procédurale + multi-fenêtres arrive ; ne bâtir dessus qu'à la beta).
📘 Option à garder ouverte : C#/.NET + Avalonia Si — et seulement si — le critère POO s'avère négociable à l'usage, c'est objectivement le stack le plus complet de 2026 : le seul GUI cross-platform mûr et stable du marché, services/daemons sans friction, binaire AOT autonome. Le test pratique ci-dessous est précisément fait pour trancher cette question sans débat théorique.
🧪 Le test qui tranche tout : la même mini-appli, deux fois Une petite application réelle (fenêtre, un peu de données, un traitement) développée une fois en Go + Fyne, une fois en C# + Avalonia, avec l'assistant IA à chaque fois. Un week-end par version. Le backend Go reste réutilisable tel quel en service/daemon quoi qu'il arrive — rien n'est perdu. À l'arrivée, deux questions auront une réponse vécue plutôt que théorique : « Fyne est-il assez mûr ? » et « la POO de C# en 2026, assistée par l'IA, me fait-elle vraiment vomir ? »

En une phrase

Go est le choix aligné avec les critères énoncés et sans regret possible sur services/daemons ; C# + Avalonia est le choix dominant sur les données brutes si le critère POO tombe ; le test pratique à deux volets coûte deux week-ends et remplace tous les débats.

11Sources

24 sources consultées, classées par fiabilité. Les affirmations clés ont été vérifiées sur les sources primaires (enquêtes officielles, docs éditeurs, API GitHub en direct).