Développeurs WinDev : la pénurie qui menace votre logiciel métier

Depuis le rachat de PC SOFT fin 2024, le débat autour de WinDev se concentre sur la facture : abonnement obligatoire, projet de facturation à la session, pétitions de développeurs. Ce débat est légitime. Mais il masque un risque plus ancien et plus silencieux : trouver un développeur WinDev capable de reprendre votre application devient chaque année plus difficile, et rien n'indique que la tendance s'inversera.

La situation est connue de tous les DSI concernés, même si elle se dit rarement en comité de direction : une grande partie des logiciels métier français repose sur une ou deux personnes qui maîtrisent le WLangage. Certaines approchent de la retraite. D'autres sont déjà parties, en laissant un code que personne n'ose toucher.

Cet article s'adresse aux dirigeants de PME, d'ETI et d'éditeurs dans cette situation. Objectif : évaluer votre exposition, la contenir à court terme, puis décider d'une trajectoire avant que le sujet ne se transforme en urgence.

Le risque numéro un n'est pas la redevance, c'est le CV de votre mainteneur

Le principal risque d'un logiciel métier WinDev n'est pas la politique tarifaire de son éditeur, c'est la dépendance à la personne qui le maintient. Une hausse de tarif se budgète, se provisionne, se négocie. Le départ du seul salarié qui comprend 200 000 lignes de WLangage ne se négocie pas : le jour où il survient, votre capacité à faire évoluer un outil critique tombe à zéro, quel que soit le montant que vous êtes prêt à payer.

Les ingénieurs ont un nom pour ça : le bus factor, soit le nombre de personnes dont la disparition soudaine bloque un projet. Pour beaucoup d'applications de gestion écrites en WLangage depuis les années 2000, ce nombre vaut 1. Parfois 0, quand le développeur historique est déjà parti et que l'entreprise vit sur un exécutable qu'elle ne sait plus recompiler.

Soyons clairs sur un point : WinDev n'est pas le problème. L'outil a équipé des milliers de PME françaises en logiciels de gestion efficaces, et les développeurs WLangage comptent parmi les plus productifs sur ce terrain. Le problème est démographique et contractuel. Il se traite comme un risque d'entreprise, pas comme une querelle de technologies.

Un vivier de développeurs WinDev qui ne se renouvelle plus

Le WLangage est un langage propriétaire, pratiqué presque exclusivement dans l'espace francophone, et son vivier de développeurs ne grandit plus. Trois signaux convergent.

D'abord, l'absence des radars internationaux. Le WLangage n'apparaît dans aucune des listes de langages publiées par la Stack Overflow Developer Survey 2025, et il est absent du top 100 de l'index TIOBE de juillet 2026, qui référence pourtant des langages aussi confidentiels que Xojo ou XPL. Un jeune développeur qui choisit sa spécialité en 2026 ne croise tout simplement jamais cette technologie.

Ensuite, la démographie de la communauté. Les échanges actifs se concentrent sur quelques forums francophones historiques, developpez.net et les forums PC SOFT en tête. Sur Reddit, le thread « Qui utilise encore WebDev/WinDev en 2025 ? » résume l'époque : la question elle-même est devenue le sujet.

Enfin, la mesure. D'après notre relevé DataForSEO (France, juillet 2026), la requête « développeur windev » pèse 140 recherches par mois. C'est un marché de niche, où chaque recrutement se compte en mois. En face, les plateformes d'emploi affichent en continu des centaines d'offres WinDev ouvertes, et le vivier TypeScript ou React se compte, lui, en centaines de milliers de développeurs formés chaque année dans le monde. Recruter sur une stack web ouverte prend des semaines ; recruter un profil WLangage expérimenté relève de la chasse.

Ce déséquilibre serait gérable si le parc installé était marginal. Il ne l'est pas. La question écrite n°16481 déposée à l'Assemblée nationale le 30 juin 2026 cite, parmi les utilisateurs de logiciels WinDev, le « ministère de l'éducation nationale, les Hôpitaux de Paris, certaines CPAM, des entreprises travaillant dans le contrôle aérien, la défense ». Un parc énorme, un vivier qui rétrécit : c'est un effet ciseaux, et il ne dépend d'aucune décision de l'éditeur.

S'ajoute un facteur aggravant depuis 2025 : l'abonnement obligatoire. D'après la presse spécialisée, le tarif catalogue de l'abonnement annuel atteint 1 068 € HT par développeur, contre 749 € avant le rachat, soit environ 43 % de hausse. Équiper un poste coûte plus cher, y compris pour de la simple maintenance corrective. La rareté des personnes se double d'un renchérissement de l'outillage.

Mesurer le bus factor de votre logiciel métier

Mesurer le bus factor de votre logiciel métier tient en trois questions : qui peut modifier le code, qui connaît les règles métier implémentées, où se trouve la documentation. Si les trois réponses désignent la même personne, votre risque est maximal, quelle que soit la qualité de son travail.

L'exercice le plus parlant reste le scénario du départ. Déroulez-le honnêtement :

flowchart TD
    A["Votre mainteneur WinDev part demain"] --> B{"Le code source complet est-il archivé,<br/>versionné et compilable hors de son poste ?"}
    B -- Non --> C["Blocage total : plus aucune modification possible.<br/>Priorité absolue : récupérer, versionner,<br/>tester une compilation complète."]
    B -- Oui --> D{"Quelqu'un d'autre connaît-il<br/>les règles métier du code ?"}
    D -- Non --> E["Logiciel figé : corrections risquées,<br/>évolutions gelées.<br/>Documenter avant toute intervention."]
    D -- Oui --> F{"Un binôme ou un contrat de<br/>maintenance est-il en place ?"}
    F -- Non --> G["Continuité fragile : tout repose sur<br/>une disponibilité individuelle.<br/>Formaliser la maintenance."]
    F -- Oui --> H["Risque contenu : choisir la trajectoire<br/>à froid, re-staffer ou porter."]

La plupart des entreprises que ce sujet concerne s'arrêtent à la première ou à la deuxième branche. Ce n'est pas une fatalité : chaque branche rouge correspond à un chantier borné, qui se lance sans attendre la décision de fond.

Sécuriser l'existant : trois gestes à faire ce trimestre

Sécuriser un logiciel WinDev existant commence par trois gestes : vérifier l'accès au code source, produire une documentation, formaliser la maintenance. Aucun des trois ne préjuge de la suite, tous restent utiles quelle que soit la trajectoire choisie.

Premier geste : l'accès au code source, vérifié et testé. Posséder un dossier « sources » ne suffit pas. Il faut vérifier que le code est complet, versionné hors du poste du développeur, et qu'une compilation aboutit sur une machine indépendante. Un code source qui ne compile que sur un seul PC est un code source que vous ne possédez pas vraiment.

Deuxième geste : la documentation. Pas un pavé exhaustif, mais l'essentiel transmissible : inventaire des modules, flux de données, règles de gestion, procédure de déploiement, versions et dépendances.

Troisième geste : formaliser la continuité. Contrat de maintenance avec un prestataire, ou binômage interne organisé tant que le sachant est là. L'objectif est le même : qu'une deuxième entité, personne ou société, soit capable d'intervenir.

Le piège classique des reprises de code hérité

Le point bloquant d'une reprise n'est presque jamais la syntaxe du langage. Le scénario, on le voit régulièrement dans les reprises d'applications héritées, toutes technologies confondues :

• Symptôme : le prestataire pressenti pour reprendre l'application rend un chiffrage prudent, assorti de réserves, alors que « le code marche très bien ».
• Diagnostic : ce ne sont pas les lignes de code qui l'inquiètent. C'est le pourquoi : vingt ans de règles de gestion implicites, de cas particuliers négociés avec des clients, de contournements jamais écrits. Cette connaissance vivait dans la tête des personnes, et elle est partie avec elles.
• Fix : capturer la connaissance métier tant qu'elle est disponible. Quelques jours d'entretiens structurés avec les utilisateurs clés et le mainteneur, convertis en tests de non-régression qui figent le comportement attendu, valent mieux que des semaines de lecture de code après le départ.

C'est la raison pour laquelle le binômage et la documentation se font maintenant, pas au moment du préavis.

Recruter un développeur WinDev ou porter vers le web : le comparatif

Deux trajectoires existent : re-staffer du WinDev pour maintenir l'existant tel quel, ou porter progressivement le logiciel vers des technologies à vivier large, typiquement TypeScript, React et PostgreSQL. Voici comment elles se comparent sur les dimensions qui comptent pour un dirigeant :

Lecture honnête de ce tableau : si votre application est stable, votre parc de versions sain et votre prestataire fiable, rester sur WinDev à moyen terme est un choix défendable. Migrer par peur, sans analyse, détruit de la valeur. Le portage se justifie quand les demandes d'évolution s'accumulent, que la dépendance individuelle est forte, et que chaque recrutement raté rapproche du scénario de blocage.

Ce qui a changé depuis cinq ans, c'est le coût d'entrée de la seconde option. Les modèles de langage lisent le code existant, en extraient les règles de gestion, génèrent la documentation de l'existant et accélèrent la réécriture module par module. L'IA ne « traduit » pas un logiciel d'un coup de baguette, et quiconque vous promet l'inverse survend. Mais elle réduit la partie la plus coûteuse du portage : comprendre ce que fait vraiment l'application. Un portage progressif, écran par écran ou module par module, avec l'application historique qui continue de tourner pendant la transition, est devenu accessible à des budgets de PME. C'est aussi l'occasion de réinterroger les besoins plutôt que de recoder l'existant à l'identique, comme on l'a détaillé à propos des CRM sur mesure.

Chez Platane, on a vécu ce scénario côté reprise : pour l'exposition « Le Peuple de demain » au Centre Pompidou, deux applications interactives existaient déjà, mais leur développement initial, lié à une technologie propriétaire et à un prestataire unique, était devenu inutilisable. On a tout recodé from scratch sur des technologies standard, et le dispositif tourne aujourd'hui sans dépendance à un fournisseur irremplaçable. Le détail est dans le cas client.

Le vrai coût du risque : un logiciel figé

Le coût réel de la pénurie ne se lit pas dans le tarif journalier d'un freelance WinDev, il se lit dans tout ce que votre entreprise ne peut plus faire quand son logiciel est figé. C'est le chiffrage que les comités de direction oublient.

Trois murs se dressent devant un logiciel que personne ne peut modifier. Les demandes clients d'abord : chaque évolution refusée pousse un client vers un concurrent équipé d'un outil vivant. Les échéances réglementaires ensuite, et la plus concrète est déjà datée : la facturation électronique impose à toutes les entreprises assujetties à la TVA de pouvoir recevoir des factures électroniques au 1er septembre 2026, puis d'en émettre au 1er septembre 2027 pour les PME et micro-entreprises. Si votre chaîne de facturation vit dans une application que personne ne sait faire évoluer, cette échéance devient un mur. Les montées de version enfin : un changement d'OS, de serveur ou de matériel finit toujours par arriver, et un exécutable non recompilable transforme une migration banale en crise.

Il existe un quatrième mur, moins visible : la valorisation. En cas de cession ou de levée, une due diligence analysera un logiciel critique maintenu par une personne unique comme un risque, et un risque s'analyse en décote. Documenter et dé-risquer votre applicatif protège la valeur de l'entreprise, même si vous ne changez rien d'autre.

La checklist avant l'urgence

Voici les cinq points à valider, dans cet ordre. Chacun se vérifie factuellement, sans expertise technique particulière :

• Accès au code source vérifié et testé : sources complètes, versionnées hors du poste du mainteneur, compilation réussie sur une machine indépendante.
• Documentation à jour ou générée : règles métier, flux de données, procédure de déploiement ; une première version assistée par IA vaut mieux qu'un document parfait qui n'existe pas.
• Au moins deux personnes capables d'intervenir : en interne ou via un contrat de maintenance actif, testé sur une intervention réelle.
• Inventaire des versions, licences et dépendances : version de WinDev, conditions d'abonnement, base de données, composants tiers, OS cibles.
• Trajectoire décidée et budgétée : maintenir, re-staffer ou porter progressivement ; une décision documentée, même si c'est « rester », vaut mieux qu'un non-choix.

Si vous cochez les cinq cases, la pénurie de développeurs WinDev est pour vous une donnée de marché, pas une menace. Si vous en cochez deux ou moins, le sujet mérite une place à l'ordre du jour de votre prochain comité, avant que le calendrier ne décide à votre place.

L'agence Platane (https://platane.io) accompagne des TPE et PME françaises exactement à cet endroit : audit de l'existant, documentation assistée par IA, et portage progressif de logiciels métier vers des technologies ouvertes, hébergées sur une infrastructure souveraine en France.

Questions fréquentes

Q: WinDev est-il une technologie morte ?

A: Non. L'éditeur publie une nouvelle version chaque année et le parc installé en France reste considérable, jusque dans des secteurs critiques cités à l'Assemblée nationale. Le risque ne porte pas sur la qualité de l'outil : il porte sur la démographie du vivier de développeurs et sur l'évolution des conditions commerciales depuis le rachat de PC SOFT.

Q: Combien de temps faut-il pour recruter un développeur WinDev ?

A: Plusieurs mois en pratique, sans garantie d'aboutir. Le vivier est restreint, expérimenté et très sollicité, et la requête « développeur windev » ne représente que 140 recherches mensuelles en France, signe d'un marché étroit. Sur une stack web ouverte comme TypeScript ou React, un recrutement équivalent se compte en semaines.

Q: Faut-il migrer une application WinDev qui fonctionne bien ?

A: Pas systématiquement. Si l'application est stable, documentée, et qu'au moins deux personnes ou un prestataire fiable peuvent intervenir, la maintenir est un choix rationnel. La migration WinDev vers le web se justifie quand la dépendance à une personne unique est forte, que les évolutions s'accumulent ou que les coûts de licence pèsent sur chaque poste. C'est une décision de trajectoire, à prendre à froid, sur la base d'un audit.

Q: Un seul développeur connaît notre application : que faire en premier ?

A: Trois gestes, dans l'ordre : récupérer et versionner le code source puis vérifier qu'il compile hors de son poste ; produire une documentation des règles métier, au besoin assistée par IA, validée avec lui ; formaliser un binôme ou un contrat de maintenance. Ces trois gestes se mènent en quelques semaines et restent utiles quelle que soit la trajectoire choisie ensuite.