Un problème simple en apparence, complexe en pratique.
Le transporteur propose à ses voyageurs un accès Wifi embarqué réservé aux détenteurs de l'option correspondante — soit les abonnés à l'option +, soit ceux ayant spécifiquement coché l'option lors de la réservation. Simple en théorie.
En pratique, le portail d'identification n'arrivait à reconnaître correctement que 30% des ayants droit. Sept voyageurs sur dix ayant payé l'option se voyaient refuser l'accès. Ce problème était ouvert depuis plus d'un an quand j'ai rejoint la mission.
"Dès l'entretien, ce sujet était présenté comme le défi principal de la mission. Le problème était connu, documenté, mais aucune solution viable n'avait émergé."
L'équipe en place travaillait sur une solution provisoire qui devait porter le taux de 30% à 60% — une amélioration réelle, mais loin de résoudre le problème à la racine.
L'intuition technique qui change tout.
En prenant connaissance du sujet et en échangeant avec les équipes, une intuition s'est formée assez rapidement : la requête d'identification était trop large. Elle cherchait dans l'ensemble des réservations actives, sans filtrer par train ni par date. Sur un volume de données aussi important, les performances s'effondraient et les résultats devenaient peu fiables.
Filtrer les réservations par numéro de train et par jour. Réduire le périmètre de recherche au strict nécessaire — les voyageurs présents dans ce train précis, à cette date précise. Une approche qui paraissait évidente une fois formulée.
La première réaction de l'équipe : le numéro de train n'était pas disponible dans le système. Puis qu'il n'était pas fiable. Puis que le système n'était pas capable de faire ce tri. En cherchant dans la documentation technique du prestataire réseau, j'ai trouvé que la requête existait déjà, documentée, prête à l'emploi.
Proposer une solution simple à un vieux problème, c'est rarement bien reçu.
Convaincre n'a pas été simple. Les résistances se sont succédé, chacune nécessitant une réponse concrète et documentée.
-
1
"Le numéro de train n'est pas disponible"
Le numéro était déjà présent dans l'interface existante. La donnée était là, visible, inexploitée.
-
2
"Cette donnée n'est pas fiable"
Argument difficile à invalider sans test. Il a fallu documenter et démontrer la fiabilité par la preuve.
-
3
"Le système ne peut pas faire ce tri"
La documentation du prestataire réseau indiquait le contraire. Présenter la requête existante au DSI a mis fin à cet argument.
-
4
Les dynamiques d'équipe
Arriver avec une solution que personne n'avait vue crée des frictions. Ce n'est pas une question de technique — c'est une question humaine, qui se gère avec tact et patience.
Un discours clair vaut mieux qu'une promesse optimiste.
Parallèlement aux discussions techniques, j'ai eu l'occasion d'échanger directement avec la cliente finale. Ce que j'ai compris : elle ne voulait pas de fausses promesses ni de solutions intermédiaires habillées en victoires définitives.
Elle voulait une solution fiable et pérenne, même si ça prenait un peu plus de temps. En adoptant un discours transparent sur l'état réel du problème et sur ce que ma solution pouvait apporter concrètement, elle a choisi de reporter le patch provisoire — qui aurait porté le taux à 60% — pour attendre une solution plus solide.
"Un client bien informé prend de meilleures décisions. C'est l'une des leçons les plus importantes que je retiens de cette mission."
De 30% à quasi 100%.
Ma solution a été adoptée et implémentée. Le taux d'identification est passé de 30% à quasi 100%. J'avais également prévu un mécanisme de sécurité pour les voyageurs ayant changé de train le même jour — une recherche élargie sur l'ensemble des trains de la journée pour ne priver personne d'un accès légitime.
Taux d'identification porté de 30% à quasi 100% — problème résolu en 3 mois après plus d'un an de blocage.
La solution finale est aussi plus robuste que le patch provisoire qu'elle remplaçait — elle traite le problème à la source plutôt que de le contourner.
Ce que cette mission m'a appris.
Quand on est trop proche d'un problème depuis trop longtemps, on finit par accepter ses contraintes comme des données immuables. Un regard neuf peut débloquer des situations que tout le monde pensait insolubles.
Avant d'accepter qu'une donnée n'est "pas disponible", chercher dans la documentation. La réponse était là, dans les specs du prestataire, attendant d'être lue.
Un client à qui on parle honnêtement préfère souvent attendre une vraie solution plutôt qu'accepter une demi-mesure vendue comme une victoire.
La solution technique n'est que la moitié du travail. L'autre moitié, c'est créer l'adhésion — avec les équipes, avec le management, avec le client.