Dette métier : quand les équipes façonnent des systèmes qui tiennent

Sous mon parasol, carnet en main, j'écoute les vagues et je pense à ce qui fait vraiment tenir un projet : les gens.

Cet article, dans la série "Un CTO à la plage", s'inscrit dans ma réflexion sur l'Ingénierie Holistique des systèmes de développement. C'est une vision où code, matériel et équipes métiers forment un écosystème fluide, capable de surfer les imprévus sans sombrer dans la dette -- technique ou pas.

Pourquoi le métier doit être au cœur

Un projet d'application, avec ou sans IA, c'est comme une vague : puissant, mais capricieux. Si on ne comprend pas le courant -- les besoins réels des utilisateurs -- on risque de boire la tasse.

Trop de projets échouent parce que les équipes métiers, celles qui vivent le terrain au quotidien, sont tenues à l'écart. On leur donne un cahier des charges rigide, on code dans son coin, et quelques semaines après la mise en production, une situation imprévue fait tout capoter.

Un client qui a besoin de deux formulaires différents ? Pas prévu. Un autre qui est à la fois client et fournisseur ? Oups. Résultat : contournements dans la CRM, doublons, et un "master data" qui devient un cauchemar.

Ce n'est pas juste de la dette technique. C'est une dette métier : des processus bancals, des cas mal couverts, une automatisation qui se dérègle. La dette métier, c'est quand le système s'éloigne du réel, et que les humains doivent rattraper les bugs de conception par de l'énergie manuelle.

Ma solution : intégrer les équipes métiers dès la conception. Et c'est là que les principes du Lean inspirés de Toyota m'ont ouvert les yeux : partir du terrain, respecter les savoirs pratiques, et concevoir en adaptant en continu.

Écouter le terrain pour surfer mieux

Les équipes métiers, ce sont les surfeurs qui connaissent la mer. Elles savent ce qui fonctionne, ce qui coince, et ce qui peut arriver. Mais trop souvent, on les laisse sur la plage.

Certaines startups pensent que ce n'est pas leur rôle de concevoir des applications. Et certaines équipes métiers pensent qu'elles n'ont ni le temps, ni les compétences. Erreur. Leur expérience est une mine d'or.

Ce que je fais ? J'écoute.

Je pose des questions simples : "Qu'est-ce qui vous ralentit au quotidien ?" et "Quels cas bizarres rencontrez-vous ?"

Sur un projet récent, une équipe métier m'a alerté sur des clients qui jonglaient entre plusieurs rôles (client, fournisseur, partenaire). Sans leur input, on aurait codé un système rigide, incapable de gérer ces cas hybrides. En les impliquant, on a conçu une base de données flexible, sans doublons ni chaos.

Quand le metier devient co-constructeur

Impliquer les équipes métiers, ce n'est pas seulement utile pour éviter les bugs : c'est valorisant.

Au début, il y a toujours un peu de fébrilité. Les collaborateurs n'ont pas encore confiance dans le résultat, parfois même pas dans leur propre légitimité à participer à la conception. Mais très vite, dès qu'ils voient leurs idées se traduire dans un outil concret -- et surtout qu'on corrige avec eux ce qui coince -- une forme de fierté émerge. Ce n'est plus "l'outil de l'IT", c'est leur outil de travail, façonné avec eux.

Et cette implication a un impact managérial direct : les utilisateurs deviennent des ambassadeurs du changement, ils partagent leurs retours avec leurs collègues, et surtout, ils s'en saisissent.

Même côté maîtrise d'ouvrage, on sent la différence. Les outils sont plus adaptés, plus robustes, et les KPI le montrent.

Mais souvent, j'ai cette sensation étrange que la valeur réelle du changement est difficile à capter. Pourquoi ? Parce qu'on oublie vite d'où on vient : avant, c'était un stylo, une feuille, et beaucoup de sueur. Et surtout, parce que la comparaison avec les concurrents -- qui galèrent encore avec leurs vieux outils -- est rarement mesurée.

Et c'est ok : les KPI restent importants. Mais en creux, il y a une valeur d'usage, une avance metier, que l'on ne voit pas toujours mais qui fait toute la difference.

Tester avec le métier : la clé pour éviter les surprises

Impliquer les métiers, ce n'est pas juste leur demander leur avis une fois. C'est les faire tester dès les premières itérations. Pourquoi ? Parce que le terrain révèle des vérités qu'aucun cahier des charges ne prévoit.

Sur un projet d'automatisation sensible, j'ai fait tester les utilisateurs dès l'alpha. Ils ont repéré un cas où un formulaire ne couvrait pas une situation rare mais critique. On a ajusté en une journée, avant que ça ne devienne un bug en production.

Tester avec le métier, c'est comme vérifier sa planche avant de surfer. Ça prend un peu de temps au début, mais ça évite de se retrouver à la dérive plus tard.

Modularité : un système qui absorbe les chocs

Pour surfer les imprévus, un système doit être comme un radeau : chaque partie peut bouger sans couler l'ensemble. Dans un projet SMS, j'ai conçu une architecture où chaque composant -- API, traitement des données, interface -- était indépendant.

Quand le client a changé ses besoins 7 fois en quelques semaines, on a pivoté sans réécrire le cœur. Cette modularité évite la dette technique, mais aussi la dette métier, car elle permet d'intégrer rapidement les retours du terrain.

Métriques : voir les vagues avant qu'elles n'arrivent

Un bon surfeur scrute l'horizon. Dans mes projets, j'intègre des métriques dès le départ : logs, timings, stats sur chaque composant. Ça agace parfois les équipes IT -- trop de logs ! -- mais c'est ma vigie.

Pour mAIstrow, mon IA souveraine et économe, ces métriques m'ont permis d'optimiser l'inférence pour qu'elle tourne vite, même sur du matériel léger. Et avec les équipes métiers, je partage ces données pour qu'elles comprennent ce qui se passe et proposent des ajustements.

Simplicité : l'élégance d'une solution qui dure

Un système compliqué, c'est une vague qui vous engloutit.

Je cherche la simplicité, comme un vieux processeur 8 bits qui faisait des miracles avec peu. Pas besoin de tout recoder. Juste une astuce légère, une fonction bien pensée, qui garde la solution fluide et économe.

Là encore, j'ai beaucoup appris de Plan9, ce système d'exploitation qui pousse la cohérence et la simplicité à son paroxysme. Un modèle de minimalisme fonctionnel.

Une derniere vague avant la baignade

Construire un système, c'est comme apprendre à surfer avec une équipe. Il faut :

• écouter ceux qui connaissent la mer,
• construire un radeau souple,
• et garder les yeux ouverts.

En 30 ans de projets, j'ai appris que les meilleurs systèmes naissent quand les équipes métiers sont au cœur du processus.

Les Principes Lean Toyota constituent l'épine dorsale du Système de Production Toyota et sont largement reconnus comme la pierre angulaire de la production au plus juste dans le monde entier. La méthode Toyota, formalisée en 2001, incarne cette approche à travers un ensemble de principes directeurs et de pratiques de gestion centrés sur deux piliers : l'amélioration continue (Kaizen) et le respect des personnes pour créer des solutions qui durent.

Et sur la plage, carnet en main, je me dis que c'est bien ce qu'il faut faire.

Vous avez une astuce pour impliquer les équipes métiers dans vos projets ? Écrivez-moi, je lis vos retours entre deux plongeons.