Comprendre le système réel

Comprendre le système d’abord

Avant de choisir une technologie, nous examinons comment l’application soutient le travail quotidien de l’entreprise. Qu’est-ce qui complique le service client ? Quelles opérations doivent rester disponibles, et quel résultat attend-on du changement ? Un nouveau framework, une réécriture ou l’IA peuvent être utiles, selon le problème constaté.

Partir de l’objectif et du processus

Nous demandons ce qui motive le changement : commandes trop longues à traiter, déploiements difficiles, corrections manuelles ou rapport auquel l’équipe ne se fie pas. Un problème précis permet de juger si une mise à niveau de Symfony peut le résoudre ou si une autre intervention est nécessaire. Nous relevons aussi les contraintes, comme les échéances comptables ou une campagne commerciale pendant laquelle modifier le paiement demande une attention particulière.

Nous suivons ensuite le processus choisi du début à la fin. Qui le déclenche, où se prennent les décisions et comment sait-on qu’un dossier est terminé ? Le travail effectué hors de l’application fait partie de cet examen.

Processus métier
 ├── application
 │    ├── données
 │    ├── intégrations
 │    └── traitements en arrière-plan
 └── décisions et étapes manuelles

Confronter la documentation au fonctionnement réel

Nous échangeons avec les responsables du processus, le service client, la comptabilité et l’équipe qui maintient l’application. Nous comparons leurs observations à la documentation, au code, aux données et aux journaux. Le processus décrit, la pratique actuelle et les besoins futurs peuvent différer. Un écart n’est pas forcément une erreur.

Nous cherchons les règles qui n’ont pas été documentées. Un statut apparemment inutilisé peut désigner une facture à vérifier avant l’export comptable. Avant de le supprimer ou de migrer les données, nous confirmons son rôle avec la comptabilité. Une migration doit préserver le sens des informations, au-delà de leurs valeurs enregistrées.

Nous vérifions aussi les droits : qui peut lire les données, les modifier ou valider une opération ? Les limites entre organisations et les validations hors de l’interface comptent. Afficher un bouton ne remplace pas le contrôle des accès côté serveur.

La revue technique porte sur les éléments liés au processus étudié : dépendances entre modules, tests, configuration, déploiements et traitements en arrière-plan. Pour une erreur isolée, retracer une opération peut suffire ; une modernisation plus large demande davantage d’investigation. Nous adaptons l’analyse à la décision que le client doit prendre.

Exemple : une commande et sa facture

Prenons une ancienne application Symfony fictive. Pour le client, le parcours est simple : paiement, facture et confirmation. En coulisses, la confirmation du prestataire de paiement peut arriver plus tard. Un worker, c’est-à-dire un processus exécuté en arrière-plan, crée la facture, tandis que l’export comptable suit un calendrier.

Commande
    ↓
Confirmation de paiement
    ↓
Mise à jour du statut de la commande
    ↓
Tâche dans la file de facturation
 ├── succès → facture et notification
 └── erreur → relance ou vérification manuelle

Lors d’un changement de prestataire, nous vérifions tout ce parcours. Une notification de paiement répétée ne doit pas créer une seconde facture, et les erreurs de la file doivent être visibles par l’équipe. Nous déterminons qui examine les dossiers non résolus et vérifie leur clôture avant l’export. Un formulaire de commande qui fonctionne ne permet pas, à lui seul, de le savoir.

Intégrations, exceptions et incidents

Pour les connexions au CRM, à l’ERP, aux services de messagerie ou de paiement, nous identifions les données échangées et le système qui en détient la version de référence. Nous vérifions également ce qui se passe si le prestataire ne répond pas. Une responsabilité mal définie peut conduire deux systèmes à écraser leurs corrections respectives.

Nous examinons l’état du processus après une erreur : qu’a-t-on enregistré, peut-on relancer l’opération et qui en a le droit ? Réimporter un fichier ou corriger les coordonnées d’un client après sa commande impose de tenir compte des actions déjà réalisées. L’équipe doit disposer des informations nécessaires pour reprendre le travail sans dupliquer les documents ni contourner un contrôle requis.

Certaines étapes manuelles sont des garde-fous utiles. Un montant élevé peut nécessiter une approbation, des données ambiguës un examen humain. Nous clarifions leur rôle et la personne responsable avant de proposer une automatisation.

Nous regardons aussi les déploiements. Après une mise à jour, un worker peut encore utiliser une ancienne version ou configuration. Les commandes suivent alors les nouvelles règles, tandis que les factures sont traitées selon les anciennes.

Distinguer le symptôme de la cause

Un portail lent ne demande pas forcément une réécriture. Il peut s’agir d’un seul écran qui charge tout l’historique des commandes et attend une réponse du CRM, alors que le reste fonctionne bien. Améliorer la requête ou la communication avec le CRM peut suffire.

Nous évaluons également les conséquences pour l’entreprise. Une file arrêtée peut laisser des commandes payées en attente de facture, sans que l’équipe le découvre avant une réclamation client. Cette conséquence justifie une priorité plus clairement qu’une simple liste d’erreurs techniques.

Un module fiable et bien compris mérite d’être conservé s’il ne bloque pas les évolutions nécessaires. Son âge ne suffit pas à justifier son remplacement. Nous concentrons le travail sur les pannes et les limites qui gênent l’activité ou son développement.

Définir le périmètre du changement

La recommandation précise le travail à réaliser et les éléments à conserver, comme les règles tarifaires, les droits ou les rapports historiques. Nous comparons le coût, le risque et les possibilités de revenir en arrière. Si le travail peut avancer par étapes, nous indiquons la première et les conditions pour passer à la suivante.

Problème observé
        ↓
Cause confirmée
        ↓
Impact pour l’entreprise
        ↓
Conserver / stabiliser / améliorer / remplacer

L’objectif doit permettre de vérifier le résultat. « Pouvoir changer de prestataire de paiement sans modifier les commandes, les factures ni les comptes clients » est plus précis que « mettre en place une nouvelle architecture » et fixe une condition de fin des travaux.

Ce que reçoit le client

Nous convenons des documents à produire avant l’analyse. Selon le problème, nous préparons :

• une description des processus utiles à l’analyse, des rôles et des étapes manuelles ;
• une carte des données, des intégrations et des risques ;
• les constats vérifiés, les hypothèses et les questions restant à examiner ;
• une recommandation avec son périmètre, son risque et le résultat attendu.

Nous utilisons les accès nécessaires à l’objectif convenu. S’il manque de la documentation ou qu’une décision passée ne peut pas être reconstituée, nous expliquons cette lacune et son effet sur la recommandation. Le client peut alors décider de commencer le travail ou de lever d’abord l’incertitude.