01
Ne rien faire pour l'instant
Raisonnable si
Application en fin de vie, peu de postes déployés, horizon court.
Ce que ça coûte vraiment
Rien aujourd'hui. Le risque est de décider dans l'urgence plus tard.
Sortie de WinDev, WebDev et HFSQL
Sortir de WinDev sans casser ce qui tourne autour
Cette page concerne les entreprises qui étudient une sortie de WinDev, WebDev ou HFSQL vers d'autres technologies. Si vous cherchez à monter de version WinDev, ce n'est pas notre métier, et nous vous le dirons.
- Technologies PC SOFT et WLangage depuis 2009
- Ni liés à PC SOFT, ni à une technologie cible à imposer
- Jusqu'à la production : données, échanges, bascule
Là où vous en êtes
Vous n'avez probablement pas besoin qu'on vous explique la situation
Vous avez sans doute déjà reçu un chiffrage, ou vous avez essayé d'en obtenir un. Vous avez peut-être calculé ce que représenterait une redevance appliquée à votre parc installé. Si vous vendez votre logiciel à des clients, vous vous êtes peut-être demandé comment vous alliez leur annoncer.
Nous n'allons donc pas vous refaire l'historique du dossier PC SOFT. D'autres l'ont fait, et bien fait. La question utile est ailleurs : quelle décision prenez-vous, et sur quelle base ?
Les options
Vous avez plus de deux options, et sortir n'est pas toujours la bonne
Le projet réel
Sortir de WinDev ne consiste pas seulement à réécrire du code
Réécrire le code est une partie réelle du projet, et sur certaines applications, avec des règles métier denses accumulées sur quinze ans, c'est une partie lourde. Mais c'est aussi la partie la mieux outillée aujourd'hui. Trois autres chantiers pèsent au moins autant, et sont beaucoup moins visibles au départ.
01
Le code
Des outils de conversion existent, des méthodes complètes sont publiées, un développeur compétent avance beaucoup plus vite qu'il y a trois ans. Réel, mais outillé.
02
Les données
Quinze ans d'exploitation laissent des doublons, des champs remplis différemment selon les époques, des références disparues, des champs mémo et binaires dont personne ne connaît plus le format. Reprendre ces données demande de comprendre ce que chaque cas particulier voulait dire.
03
Les échanges
Écritures envoyées à la comptabilité, commandes reçues d'un portail, CRM synchronisé, fichier déposé chaque nuit pour un partenaire, douchette ou imprimante d'étiquettes pilotée. Chaque flux a été construit à une époque précise, avec des contraintes qui ne sont écrites nulle part.
04
La bascule
Le jour où l'ancien s'arrête, tout ce qui n'avait pas été identifié se manifeste en même temps, et c'est en production que ça se règle, pas en développement.
Nous travaillons sur les quatre. Une application métier n'est jamais seule ; nous modernisons aussi ce qui la relie au reste de votre activité.
Méthode
Notre façon de travailler
Comprendre ce qui existe réellement
Le code, la structure des données, ce qui est effectivement utilisé, les traitements qui s'exécutent et les systèmes connectés. Savoir ce que fait votre application, pas ce qu'elle est censée faire.
Décider quoi faire de chaque partie
Chaque fonction reçoit une décision explicite : conserver, simplifier, améliorer, automatiser ou supprimer. Une application de quinze ans contient toujours des parties qui ne méritent pas d'être migrées.
Choisir la cible ensuite
Web, bureau, mobile, APIs, base relationnelle ouverte, hors connexion. La décision dépend de vos contraintes réelles : matériel, mobilité, déploiement, compétences, hébergement. Pas avant d'avoir regardé.
Reconstruire les flux en même temps
Les échanges avec vos autres systèmes sont traités comme une partie du projet, pas comme une reprise de l'existant. Un export de fichier utilisé depuis dix ans faute de mieux n'a pas vocation à être reproduit.
Basculer par périmètres
L'ancien et le nouveau cohabitent le temps nécessaire. Tant qu'un module n'est pas arrêté, le retour en arrière reste possible.
Vous rendre autonome
Code, dépôt Git, modèles de données, APIs documentées, procédures de déploiement, tests. Une autre équipe compétente doit pouvoir reprendre derrière nous.
Cette méthode est déroulée sur un cas détaillé, de l'inventaire à la bascule, avec un exemple de livrable.
Voir la méthode sur un cas concretVous ne savez pas encore quelle option vous concerne ? C'est précisément l'objet du premier échange. 30 à 45 minutes.
Évaluer ma sortie de WinDevPourquoi nous
Ce qui nous distingue, et ce qui nous fait dire non
Technologies PC SOFT et WLangage depuis 2009
Des applications métier développées et maintenues dans cet écosystème depuis 2009, dont une application critique reliée à plusieurs systèmes externes que nous faisons évoluer depuis plus de dix ans, bien avant les outils d'assistance actuels. Nous savons lire ce que contient votre application, pas seulement la traduire.
Des systèmes qui n'ont pas été conçus pour se parler
Salesforce et autres CRM, Sage X3, Sage 200 et autres ERP, logiciels comptables, sites marchands, APIs REST et SOAP, paiement, signature électronique, AS400, traitements planifiés. Nous concevons et exploitons ce type d'échanges en production, par exemple un middleware qui relie un ERP, une boutique en ligne et plusieurs bases, avec traçabilité, reprise sans doublon et surveillance.
Jusqu'à la production
Déploiement, exploitation, surveillance, diagnostic quand quelque chose ne va pas. La bascule fait partie du projet, pas de l'après-projet.
Quand le web n'est pas la bonne réponse
Applications de bureau, mobiles iOS et Android, fonctionnement hors ligne, pilotage de matériel. Quatre applications mobiles publiées sur les stores, dont certaines fonctionnent sans réseau.
Ni liés à PC SOFT, ni à une technologie cible
Pas de maintenance WinDev à préserver, pas de partenariat, pas de volume de migration à défendre. Si la bonne réponse est d'attendre, nous vous le dirons.
La personne qui comprend votre problème reste impliquée
Un interlocuteur senior, du diagnostic à la production, avec une production fortement outillée, et un projet découpé en périmètres livrables séparément plutôt qu'en un bloc.
Ce qui nous fait dire non
Un projet exigeant une gouvernance lourde (comités, appel d'offres formalisé, reporting contractuel) ou une parallélisation massive sur un calendrier court. Dans ces cas, d'autres acteurs sont plus adaptés, et nous vous le dirons dès l'échange.
Questions fréquentes
Ce qu'on nous demande le plus souvent
Des réponses directes, y compris quand elles ne vont pas dans notre sens.
Est-ce qu'un outil de conversion automatique ne suffirait pas ?
Parfois, oui. Si votre application est simple, isolée, sans échanges avec d'autres systèmes et sans historique de données compliqué, un outil de conversion peut vous amener assez loin pour un coût très faible. Nous vous le dirons si c'est votre cas.
Ce que ces outils produisent, c'est du code traduit. Ce qu'il vous faut, c'est un système qui tourne : avec vos données reprises, vos échanges rebranchés, vos utilisateurs qui travaillent et vos traitements automatiques qui s'exécutent. L'écart entre les deux est le projet.
Mon développeur pourrait-il le faire lui-même avec l'IA ?
Pour la partie code, souvent oui, et de mieux en mieux. Les outils d'assistance ont réellement changé ce travail, et des équipes l'ont fait en interne.
Ce que ces outils ne font pas à sa place : comprendre pourquoi une règle de gestion a été écrite ainsi en 2013, décider quelles données méritent d'être reprises, et gérer une bascule en production. Si votre développeur connaît bien l'application, c'est un atout considérable : nous travaillons volontiers avec lui plutôt qu'à sa place.
Faut-il migrer HFSQL avant ou après l'application ?
Cela dépend de la raison pour laquelle vous migrez. Sortir de HFSQL en premier est un chantier autonome : il ouvre vos données, réduit une dépendance, et a de la valeur même si vous ne changez jamais l'application. Mais si vos écrans doivent changer de toute façon, tout faire en même temps évite de payer deux fois la reprise des données.
Combien de temps, et combien ?
Nous ne pouvons pas répondre honnêtement sans avoir regardé, et une fourchette donnée sans rien connaître de votre application ne vous servirait à rien. Ce que nous pouvons faire dès le premier échange, c'est vous dire de quel ordre de grandeur relève votre situation et quels facteurs la feront varier.
Est-ce que je risque de perdre des règles métier ?
C'est le risque principal, et il ne se traite pas par une promesse. Il se traite en identifiant les règles avant de toucher au code, en les vérifiant avec les personnes qui les utilisent, et en comparant le comportement de l'ancien et du nouveau pendant la période où les deux tournent.
Et si PC SOFT revient en arrière ?
C'est possible, et c'est une raison légitime d'attendre avant d'engager un projet complet. Cela dit, certains travaux gardent leur valeur dans tous les cas : savoir ce que contient votre application, ouvrir vos données, exposer vos traitements par des APIs. Ils ne dépendent pas de l'issue de ce dossier.
La prochaine étape
Évaluer votre sortie de WinDev
Quelques questions sur votre application (sa taille, ses postes déployés, sa base, ce à quoi elle est reliée, ce qui motive votre réflexion), puis un échange de 30 à 45 minutes. Pas besoin de nous donner accès à votre code.
Nous en discutons quatre choses : sur quoi vous êtes réellement exposé ; à quoi votre application est reliée ; vos options, y compris ne rien faire pour l'instant ; ce que nous recommandons. Selon votre situation, vous repartez avec une réponse directe, une note courte, ou une proposition d'audit technique si un vrai projet se dessine. L'audit est une prestation distincte, payante, et son livrable vous appartient.