Le live coding consiste à ajuster le logiciel en séance, devant les personnes qui l'utiliseront, au lieu de recueillir leurs remarques pour les traiter des semaines plus tard. Un agent décrit ce qui le gêne, le développeur modifie l'écran, l'agent vérifie aussitôt. Cette boucle courte remplace des mois d'allers-retours et produit un outil que les équipes reconnaissent comme le leur.
Qu'est-ce que le live coding dans un projet de logiciel métier ?
Dans un projet classique, les utilisateurs expriment un besoin, quelqu'un le transcrit dans un document, un développeur l'interprète, puis une version revient plusieurs semaines après. À chaque passage de relais, une partie du sens se perd. Le live coding supprime ces relais. Le développeur s'installe dans le service concerné, projette l'écran en cours de construction et travaille avec les agents présents.
Il ne s'agit pas d'une démonstration. Une démonstration montre un produit fini que l'on commente poliment. Une séance de live coding part d'une version de travail, volontairement imparfaite, que l'on corrige ensemble : l'ordre des champs, les libellés, les contrôles de saisie, les états d'un dossier, le contenu d'un reçu ou d'un bordereau. Ce qui peut être modifié sur place l'est sur place. Ce qui demande une réflexion plus lourde est noté, expliqué et planifié.
Pourquoi les ajustements en temps réel changent-ils le résultat ?
La raison est simple : personne ne sait décrire parfaitement son travail à froid. Un caissier, une sage-femme ou un magasinier accomplit chaque jour des gestes devenus si naturels qu'il oublie de les mentionner en réunion. C'est en voyant l'écran qu'il réagit : « ici, je n'ai jamais cette information au moment de la saisie », « ce cas existe, mais une fois par mois, et il bloque tout ».
Ces remarques valent plus que n'importe quel document de spécifications, à condition d'être traitées immédiatement. Lorsqu'une correction arrive trois semaines après, l'utilisateur a oublié le contexte, et il a surtout conclu que son avis ne comptait pas. Lorsqu'elle apparaît à l'écran dans la minute, il se produit l'inverse : il propose davantage, il teste, il signale les exceptions. Le logiciel s'approche du travail réel à chaque échange.
Comment se déroule une séance, concrètement ?
Une séance utile se prépare. Elle porte sur un périmètre précis, réunit les bonnes personnes et ne dure pas au point d'épuiser un service qui doit continuer à fonctionner. Le déroulement type ressemble à ceci :
- Rejouer un cas réel. Un agent traite un vrai dossier de la veille dans la version de travail, sans aide.
- Observer les hésitations. Chaque arrêt, chaque question, chaque retour en arrière signale un point à revoir.
- Corriger à l'écran. Le développeur modifie, l'agent recommence le même cas et valide ou non.
- Arbitrer les désaccords. Quand deux agents ne travaillent pas de la même façon, le responsable du service tranche sur place.
- Consigner les décisions. Ce qui a été changé, ce qui reste à faire et pourquoi, dans un relevé court partagé le jour même.
La présence du responsable compte autant que celle des agents. Sans lui, les séances révèlent des divergences de pratique que personne n'a l'autorité de résoudre, et le logiciel finit par refléter la préférence de celui qui a parlé le plus fort.
Un cas typique : le guichet qui ne suivait pas l'écran
Prenons un service de guichet qui encaisse des redevances. La première version suivait l'ordre logique du règlement : identification de l'usager, nature de la redevance, montant, paiement. En séance, l'agente la plus expérimentée s'arrête au deuxième écran. Dans la pratique, les usagers arrivent avec un avis de paiement et ne connaissent que le numéro inscrit dessus. Elle commence toujours par ce numéro, et le reste en découle.
L'écran est réorganisé pendant la séance : saisie du numéro d'abord, informations préremplies ensuite. Elle rejoue trois dossiers, puis signale un second point : certains usagers paient pour plusieurs avis à la fois. Le cas est ajouté à la liste et traité le lendemain. Aucune réunion de cadrage n'aurait fait émerger ces deux points, parce que personne ne les considérait comme des informations à mentionner.
Quelles sont les limites du live coding ?
La méthode n'est pas magique. Elle fonctionne pour tout ce qui touche à l'usage et ne remplace pas le travail qui se fait hors séance. Un développeur qui modifierait la structure des données à chaud devant un public prendrait un risque inutile.
| Se traite en séance | Se traite hors séance |
|---|---|
| Ordre et libellés des champs | Architecture et modèle de données |
| Parcours d'un dossier, étapes de validation | Sécurité, chiffrement, gestion des profils |
| Règles de gestion et cas particuliers | Tests de charge et de non-régression |
| Documents produits : reçus, bordereaux, états | Synchronisation et reprise des données existantes |
Elle exige aussi un profil particulier. Il faut des équipes capables de comprendre le métier assez vite pour distinguer une vraie règle d'une habitude personnelle, et d'expliquer simplement pourquoi une demande aura des conséquences ailleurs. Enfin, elle suppose un travail préalable sérieux : on ne co-construit bien que ce dont on a déjà compris les grandes lignes. C'est le rôle du diagnostic de terrain, qui précède toujours la première séance.
Ce que les équipes en retirent au-delà du logiciel
Le bénéfice le moins visible est le plus durable. Des agents qui ont vu leurs remarques devenir des écrans n'ont pas besoin d'être convaincus d'utiliser l'outil : ils y ont contribué. La formation qui suit s'en trouve allégée, car une partie du service connaît déjà les parcours et peut les expliquer aux collègues avec ses propres mots. C'est l'une des raisons pour lesquelles les solutions personnalisées fonctionnent là où des outils imposés restent inutilisés.
La direction y gagne également. Les séances font remonter des écarts entre la procédure écrite et la pratique réelle, que personne n'avait formulés jusque-là. Certains écarts sont des erreurs à corriger, d'autres sont des adaptations intelligentes que la procédure officielle devrait intégrer. Dans les deux cas, la décision est prise en connaissance de cause.
Chez Linking Development, nous pratiquons ces séances dans les services eux-mêmes, à Abidjan, Dakar ou Conakry, et nous constatons que les premières heures passées devant l'écran avec les agents évitent les corrections les plus lourdes après la mise en service.
Si vous préparez un projet et souhaitez que vos équipes participent à sa construction plutôt que de le découvrir le jour du déploiement, découvrez notre façon de concevoir des solutions sur mesure.