6.2Problèmes récurrents (playbook)
L'essentiel en 30 secondes
- Nommer : un incident se traite mieux avec un symptôme précis (« le champ reste vide ») qu'avec une impression (« ça ne marche pas »).
- Chercher la cause : liaison, requête, droits, dépendances, transaction — la même gêne peut venir de plusieurs étages.
- Corriger à la racine : l'action ciblée évite que le symptôme revienne la semaine suivante sous une autre forme.
Fil Yacine — le carnet d'incidents
Yacine tient un carnet d'incidents pour l'application du négoce. Chaque entrée note le symptôme vu par l'utilisateur, la cause probable et l'action qui a réglé le problème. Au fil des mois, les mêmes familles reviennent : champs mal liés, requêtes trop larges, droits mal appliqués, dépendances oubliées au déploiement et mises à jour risquées.
Réflexe : nommer le symptôme, vérifier la cause, appliquer l'action ciblée — et repérer le fondamental manquant derrière un symptôme qui revient.
Un incident, un symptôme
La première erreur est de corriger au hasard. On commence par reproduire l'incident et le décrire précisément : quel écran, quel champ, quel utilisateur, quelles données. Un symptôme clair divise déjà le temps de diagnostic.
Du symptôme à la cause
La même gêne peut venir de la liaison des champs, d'une requête mal filtrée, d'un droit mal configuré ou d'une dépendance absente. On remonte les étages un par un : données, code, interface, environnement.
Corriger sans revenir en arrière
Une correction durable s'accompagne d'un test de non-régression et, si besoin, d'une note dans le carnet. Corriger un symptôme sans la cause, c'est garantir qu'il reviendra autrement.
| Symptôme | Causes probables | Actions |
|---|---|---|
| Un champ n'affiche pas la valeur de la rubrique attendue | liaison champ/rubrique incorrecte ou champ non affecté | vérifier la liaison dans la fenêtre et le parcours ; contrôler HAjoute, HModifie et HEnDehors (N1.4) |
| L'application plante à l'ouverture chez le client | dépendances manquantes (dll, framework, pilotes) | livrer avec l'installeur complet, vérifier les prérequis et tester sur une machine vierge (N4.4) |
| Une requête devient très lente en production | filtre fait en WLangage au lieu de la base, rubriques non indexées | filtrer en SQL (WHERE), indexer les rubriques filtrées et jointes, borner la requête (N2.2) |
| Deux utilisateurs écrasent les données de l'autre | base Classic partagée ou absence de transaction | passer en Client/Serveur, encadrer les écritures par des transactions et gérer les conflits (N4.1) |
| La mise à jour automatique perd ou écrase des données | conversion de structure non testée, sauvegarde absente | sauvegarder, tester la conversion sur une copie représentative et prévoir un retour arrière (N4.4) |
| Un droit utilisateur ne s'applique pas | groupe mal configuré, contrôle uniquement côté écran | définir les groupes par rôle, vérifier côté serveur et côté interface, tester avec de vrais profils (N4.2) |
Script prêt à dire — qualifier un incident (30 s)
« Pouvez-vous me dire sur quel écran, quel champ et quel utilisateur le problème apparaît, et avec quelles données ? Je reproduis, je vérifie la cause et je corrige à la racine. »
À garder pour cadrer un incident avec un utilisateur pressé.
Script prêt à dire — annoncer une correction (30 s)
« J'ai identifié la cause : [liaison / requête / droit / dépendance]. Je corrige, je reteste le parcours complet et je livre la version avec une sauvegarde préalable. »
Utile pour rassurer sans promettre à l'aveugle.
Modèle copier-coller — fiche d'incident
Symptôme : [écran / champ / message]
Utilisateur : [profil] Données : [jeu concerné]
Reproduit : oui/non
Étage : données / code / interface / environnement
Cause probable : [...]
Action appliquée : [...]
Test de non-régression : oui/non
Version livrée : [x.y]Modèle copier-coller — requête bornée et indexée
// Filtrer côté base, borner le résultat
MaRequete est une req
MaRequete = SQLExec("SELECT * FROM Commandes WHERE DateCmd = {ParamDate} LIMIT 100")
// Vérifier l'index sur DateCmd dans l'analyse
// Ne pas ramener tout le fichier puis trier en WLangageTPE / petit budget
Tenir un carnet d'incidents simple (date, symptôme, cause, action) : la mémoire de l'équipe vaut mieux qu'un outil lourd jamais rempli.
PME Oran
Adapter aux réalités locales : postes anciens, connexions instables, interventions rapides au comptoir et explications en français simple.
Remote / multi-sites
Centraliser les journaux et documenter chaque correctif pour que le collègue à distance comprenne sans rappeler l'utilisateur.
Interculturel
Décrire le symptôme sans jargon métier avant de transposer : un message clair vaut mieux qu'un numéro d'erreur incompris.
Défi 48h — appliquez demain
Prenez un incident réel et appliquez la fiche : symptôme décrit, étage localisé, cause vérifiée, action appliquée et test de non-régression.
- Je sais qualifier un symptôme, localiser l'étage et appliquer une correction ciblée.
- J'ai une fiche d'incident réutilisable et un réflexe de non-régression.
- J'ai fait le défi 48h ou planifié sa date.
Une requête de l'application devient très lente en production. Quelle est la première action ?
Réflexe : nommer le symptôme, vérifier la cause, appliquer l'action ciblée — et repérer le fondamental manquant derrière un symptôme qui revient.