Méthode
Comment nous raisonnons
La méthode DEVGO appliquée de bout en bout à une situation réaliste : un logiciel de gestion WinDev de quatorze ans, sa base HFSQL, ses sept flux et ses équipements, de l'inventaire à la bascule.
Ce qui suit est un cas synthétique, sans aucune donnée client réelle. Chaque élément du cas correspond à une situation que nous rencontrons réellement, et le raisonnement est celui que nous appliquons, notamment sur une application métier historique que nous maintenons depuis plus de dix ans, dont le code, la base HFSQL, les logs et les intégrations CRM sont analysés conjointement pendant le développement et le diagnostic.
Le cas
Un distributeur B2B et son logiciel de gestion
Un distributeur de fournitures pour l'industrie. Une soixantaine de personnes. Son activité repose sur un logiciel développé en WinDev il y a quatorze ans, enrichi en continu depuis par deux développeurs successifs, dont le second est parti l'an dernier.
Cas synthétique · aucune donnée réelle
Ce à quoi elle est reliée
| Frontière | Comment ça marche aujourd'hui |
|---|---|
| Comptabilité | Export de fichier chaque nuit, importé le matin par la comptable. Deux fois par mois, elle corrige à la main les écritures rejetées |
| CRM | Synchronisation bidirectionnelle écrite en 2019 par le second développeur. Personne ne sait exactement ce qu'elle synchronise ni dans quel ordre |
| Site marchand | Un traitement toutes les quinze minutes pousse le stock et remonte les commandes web. Il s'arrête parfois sans prévenir |
| Deux clients grands comptes | Échanges EDI en format fixe, définis contractuellement il y a dix ans. Toute modification demande un avenant |
| Transporteur | Fichier CSV déposé sur un serveur SFTP chaque soir à 18 h |
| Entrepôt | Deux balances connectées en série et trois imprimantes d'étiquettes pilotées directement par l'application |
| Facturation | Un service Windows génère les factures PDF et les envoie par mail ; il tourne sur le serveur de fichiers, sous le compte d'un utilisateur parti depuis trois ans |
Pourquoi l'entreprise se pose la question. Son abonnement WinDev arrive à échéance. Un chiffrage de redevance sur ses 57 postes lui a été présenté. Et le développeur qui connaissait l'application n'est plus là.
Ce que nous faisons, dans l'ordre
Dix étapes, et le résultat de chacune sur ce cas
-
Inventaire : ce qu'il y a
Nous commençons par lister ce qui existe, sans juger : fenêtres, procédures, tables, requêtes, états, traitements planifiés, services, fichiers échangés, équipements.
L'inventaire n'est pas la cartographie. C'est le matériau.
Sur ce cas340 fenêtres, 1 900 procédures, 87 tables, 23 états, 6 traitements planifiés, 1 service Windows, 7 flux externes, 5 équipements.
-
Cartographie : ce qui dépend de quoi
Quelles fenêtres appellent quelles procédures, quelles procédures touchent quelles tables, quelles tables sont lues par quels flux. L'application écrit un journal d'utilisation dans une table HFSQL depuis 2017 : nous le croisons avec l'inventaire.
Sur ce cas71 fenêtres n'ont pas été ouvertes depuis plus de deux ans.
- 18 procédures ne sont appelées par rien.
- 9 tables ne sont ni lues ni écrites, mais 2 d'entre elles sont lues par le flux comptable.
-
Règles métier : ce que l'application décide
C'est le travail le plus long et le moins automatisable. Nous lisons le code des traitements qui comptent (tarification, remises, disponibilité, calcul de commission) et nous les confrontons aux personnes qui les utilisent.
Sur ce casLa règle de remise comporte 14 cas particuliers.
- 4 correspondent à des clients qui n'existent plus.
- 1 contredit une règle écrite plus tard et ne s'applique jamais.
- Les 9 restantes sont le cœur du métier et doivent être reprises exactement.
-
Flux : comment l'application parle aux autres
Chaque frontière du tableau est documentée : quoi, quand, dans quel format, qui consomme, que se passe-t-il en cas d'échec.
Sur ce cas- La synchronisation CRM envoie les contacts dans un sens et les opportunités dans l'autre, avec un mécanisme de rejeu qui crée des doublons quand le CRM répond lentement.
- Le traitement du site marchand s'arrête sur référence inconnue.
- Le fichier transporteur est en réalité lu par deux systèmes, pas un.
-
Dépendances : ce qui bloque
Ce qui ne peut pas changer sans accord externe, sans matériel, ou sans risque comptable.
Sur ce cas- Sans accord externe : les deux flux EDI, contractuels.
- Sans matériel : les balances (protocole série propriétaire) ; les imprimantes utilisent un langage d'étiquettes standard, donc remplaçable.
- Sans risque comptable : le format d'export, jusqu'à la prochaine clôture.
-
Données : ce qu'il y a vraiment dedans
Avant de décider où vont les données, nous regardons ce qu'elles contiennent. Chacun de ces points est une décision à prendre, pas un problème technique à résoudre en silence.
Sur ce cas- Table clients : 3 400 enregistrements dont 600 doublons créés par la synchronisation CRM.
- Le champ « code postal » a connu trois formats successifs.
- 1 200 lignes de commande pointent vers des articles supprimés.
- Un champ mémo contient des conditions commerciales en texte libre, que la règle de remise lit par recherche de mots-clés.
-
Décider : conserver, simplifier, améliorer, automatiser, supprimer
Chaque élément reçoit une décision explicite, écrite, discutée avec l'entreprise. La nouvelle application couvre 275 fenêtres d'usage, pas 340. Et certaines choses ne changent pas du tout.
Sur ce cas, 340 fenêtres réparties ainsi140ConserverLes 9 règles de remise actives, la logique de disponibilité, les flux EDI tels quels.
60Simplifier6 écrans de saisie de commande fusionnés en 2 ; la règle de remise débarrassée de ses 5 cas morts.
45AméliorerLa saisie itinérante, qui doit fonctionner hors réseau et se synchroniser proprement ; le suivi de préparation.
30AutomatiserL'import comptable : plus de fichier, plus de correction manuelle ; la reprise du traitement site marchand sur référence inconnue.
65SupprimerLes 71 fenêtres inutilisées, moins 6 qui servent une fois par an à la clôture.
-
Architecture cible : décidée après, pas avant
Ce cas a trois populations avec trois contraintes : le siège (bureau, réseau stable), l'entrepôt (matériel connecté, poste fixe), les itinérants (hors ligne, portable). Une seule réponse technique ne convient pas aux trois. Ce que nous retiendrions ici, et qui serait différent sur un autre cas :
Cible retenue sur ce casApplication webpour le siège et la gestion.Application mobile hors lignepour les itinérants, avec une synchronisation conçue pour le conflit, pas pour le cas idéal.Agent local léger à l'entrepôtà côté de l'application web, pour piloter balances et imprimantes.Base PostgreSQLouverte, requêtable par d'autres outils.Middlewareportant les flux comptables, CRM, site marchand et transporteur, avec traçabilité de chaque échange, rejeu sans doublon, et alerte quand un flux échoue au lieu de s'arrêter en silence.Flux EDI conservés à l'identiqueréécrits dans le middleware mais produisant exactement le même format. -
Coexistence : l'ancien et le nouveau ensemble
Rien ne bascule en une nuit. La trajectoire est détaillée dans la bande ci-dessous : la base d'abord, le middleware ensuite, puis les périmètres applicatifs un par un.
PrincipeÀ chaque étape, l'ancien reste accessible tant que le nouveau n'est pas validé. Pendant deux clôtures mensuelles, l'ancien export comptable et le nouveau flux tournent en parallèle et sont comparés.
-
Bascule : le jour où l'ancien s'arrête
Il n'y a pas un jour, il y en a cinq, un par périmètre. Pour chacun : un critère de validation défini à l'avance, une période de fonctionnement parallèle, un retour arrière possible tant que l'ancien module n'est pas désactivé, et quelqu'un qui surveille les logs le lendemain matin.
Ce qu'on ne découvre qu'en regardantLe service Windows de facturation, qui tournait sous le compte d'un utilisateur parti, est remplacé au passage. Personne ne l'avait demandé.
Coexistence
La trajectoire sur ce cas, en cinq périmètres
L'ordre n'est pas technique, il est économique : on commence par ce qui ouvre le plus, puis par ce qui coûte le plus en travail manuel.
- La base d'abordHFSQL vers PostgreSQL, application WinDev existante reconnectée. L'entreprise travaille comme avant ; les données sont ouvertes.
- Le middleware ensuiteFlux repris un par un, comptabilité d'abord, parce que c'est là que le travail manuel coûte le plus.
- L'application itinérantePérimètre isolé, population identifiable, gain immédiat. Premier module neuf en production.
- Le siège, domaine par domaineCommandes, puis stock, puis facturation. L'ancienne fenêtre reste accessible tant que la nouvelle n'est pas validée.
- L'entrepôt en dernierParce que le matériel impose des tests sur site.
Le livrable
À quoi ressemble ce que nous rendons
Voici, sur ce même cas fictif, l'exemple d'une note de diagnostic d'orientation, ce que nous produisons après un premier échange, quand la situation le justifie. Elle tient en trois pages. Elle est écrite pour être présentée à une direction.
Version imprimable. Toutes les données de ce document sont fictives.
Ce que ce cas permet de voir
Appliquer ce raisonnement à votre application
Ce cas montre comment nous décidons ce qui se conserve, ce qui se simplifie et ce qui disparaît, comment les flux et les données sont repris, et comment la bascule se fait par périmètres. Le cas est volontairement de taille moyenne pour rester lisible. Sur un système plus étendu, plusieurs sociétés, un ERP central, davantage de flux, le raisonnement est le même ; ce sont le nombre de périmètres et l'ordre de bascule qui changent. Si votre situation ressemble à ce cas, ou pas du tout, le plus utile est de dérouler le même raisonnement sur votre application.