Document d'exemple. Toutes les données sont fictives. Ce document illustre le format et la densité d'une note de diagnostic d'orientation DEVGO sur le cas synthétique décrit ici.

Note de diagnostic d'orientation

Cas synthétique, distributeur B2B · Rédigée après un échange de 45 minutes, sans accès au code source · 3 pages

1. Situation

Application de gestion développée en WinDev, application de bureau Windows, 14 ans, environ 340 fenêtres, base HFSQL Client/Serveur de 87 tables. 57 postes, dont 45 au siège et à l'entrepôt et 12 commerciaux itinérants avec besoin de saisie hors réseau.

Le développeur qui connaissait l'application est parti l'an dernier. L'abonnement WinDev arrive à échéance et un chiffrage de redevance sur les postes déployés a été reçu.

2. Exposition

Postes exposés : 57. Sessions estimées selon la définition rapportée publiquement (un utilisateur, une machine, une application, un type de base) : 57 à 69, la variation venant des postes utilisant deux applications distinctes.

Coût annuel : à établir sur le devis reçu. Nous ne publions pas de grille tarifaire ; PC SOFT n'en a pas publié d'officielle au moment de cette note.

Exposition non tarifaire, plus importante à notre avis : un seul sachant sur l'application, et il est parti. Aucune documentation des flux. Le service de facturation tourne sous un compte utilisateur obsolète.

3. Ce à quoi l'application est reliée

7 flux externes, 5 équipements, 1 service Windows. Points de fragilité identifiés à l'échange :

  • synchronisation CRM non documentée ; doublons probables sur les contacts ;
  • service de facturation sous compte utilisateur d'une personne partie ;
  • traitement site marchand sans reprise sur erreur : il s'arrête sur référence inconnue ;
  • export comptable corrigé à la main deux fois par mois ;
  • flux EDI contractuels avec deux grands comptes : à ne pas toucher sans avenant.

4. Options

OptionÉvaluation sur ce cas
Ne rien fairePossible 12 mois. Le risque principal n'est pas la redevance mais la perte de connaissance : personne ne sait plus comment l'application fonctionne.
NégocierPertinent en parallèle de toute autre option. N'adresse ni le sachant parti ni le besoin hors ligne.
Geler la versionAchète du temps. N'adresse pas le sachant parti ni les flux fragiles.
Moderniser dans l'écosystèmeRéduirait la dette. Ne change ni la dépendance ni le besoin hors ligne des itinérants, non couvert aujourd'hui.
Sortir progressivementJustifié : application stratégique, horizon supérieur à 5 ans, besoin hors ligne non couvert, flux à reprendre de toute façon.
Remplacer par un progicielÉcarté : règles de remise et flux EDI trop spécifiques pour un progiciel standard.

5. Recommandation

Sortie progressive, dans cet ordre : la base d'abord (HFSQL vers PostgreSQL, application existante reconnectée), le middleware ensuite (flux comptable en premier, parce que c'est là que le travail manuel coûte le plus), puis l'application itinérante comme premier module neuf.

Avant tout engagement : un audit technique ciblé sur les flux CRM et comptable, qui conditionnent la trajectoire et dont le fonctionnement réel n'est connu de personne.

6. Prochaine étape

Audit technique. Périmètre : cartographie complète, analyse des données, documentation des 7 flux, chiffrage par périmètre. Prestation payante. Le livrable est transférable et reste utile quel que soit le prestataire retenu ensuite.


Fin du document d'exemple. Retour à la méthode · Faire le point sur mon application