Notes du gemba : Leçon de lean chez l’éditeur de logiciel No Parking

Lille, la grande ville du Nord de la France, a connu une époque florissante avec l’industrie textile au XIXe et début XXe. Aujourd’hui, deux anciennes usines textiles abritent le pôle lillois de la Tech et l’entreprise que je viens visiter, No Parking, est à deux pas. Comme le disait en 2017 un article du journal Les Echos : A Lille, la Tech grandit sur les ruines du textile.

Perrick Penet qui me reçoit est le gérant de No Parking. Je lui demande l’origine du nom, alors que nous rejoignons sa petite équipe de 8 personnes. “No Parking, m’explique-t-il, c’est l’information en mouvement, qui ne stagne pas.” L’entreprise a créé et développé un outil de gestion de temps, Opentime, il y a 20 ans. “Nous avions commencé comme entreprise de services informatiques et j’avais développé Opentime pour notre propre usage. Sollicité par mon comptable pour une de ses entreprises clientes, on a commencé à le vendre. Aujourd’hui, plus de 200 entreprises et associations l’utilisent.” Opentime représente 85 % du chiffre d’affaires de l’entreprise.

Dans un monde qui va vite, et c’est encore plus vrai dans la Tech, comment survit-on quand on est petit, face aux grands éditeurs de logiciel, voire aux solutions in-house que l’IA permettra sans doute de développer demain ? Certes, No Parking sert au moins en partie un marché de niche : cabinets d’avocats, d’architecture, d’experts comptables, bureaux d’études, start-ups de la Tech, associations, moins susceptible d’attirer les gros éditeurs.

Mais la concurrence est rude et la résilience de No Parking est largement soutenue par l’approche double que je suis venue voir sur le terrain : Perrick, qui a étudié de près le rôle d’un Chief Engineer chez Toyota, travaille en permanence sur les valeurs ou fonctionnalités nouvelles que l’équipe peut apporter aux clients. Et il encourage par ailleurs, semaine après semaine, le développement des savoirs au sein de cette équipe.

Développer de la valeur pour les clients ? Indispensable pour survivre

Perrick me montre le produit Opentime qui surprend par la simplicité et l’ergonomie des ses écrans. Pas de navigation sophistiquée, ni de design superfétatoire, l’idée est d’aller directement à la fonctionnalité et à la valeur pour le client. L’équipe de No Parking est en outre utilisatrice d’Opentime pour ses propres besoins, ce qui lui permet d’en repérer les manques ou dysfonctionnements.

Comme tout bon logiciel, il est mis à jour plusieurs fois par jour, en tenant compte des corrections ou évolutions demandées par les utilisateurs. Peu enclin à envoyer des questionnaires de Net Promoter Scores tous azimuts au risque de lasser les clients, Perrick demande à l’équipe de cibler uniquement les nouveaux clients, après leur prise en main, et tous les utilisateurs demandeurs d’évolution, afin de comprendre ce qu’il faut encore travailler. Il me montre pour chaque échange ainsi ciblé des PDCAs permettant de résoudre les problèmes jusqu’à la complète satisfaction du client.

L’équipe apporte aussi un service apprécié des utilisateurs : un blog relate en détail les dernières évolutions apportées, montre comment gérer un point précis de la réglementation du travail ou raconte l’expérience d’utilisation d’un des clients.

Mais optimiser l’existant n’est qu’une partie du rôle de Chief Engineer. L’exploration chez les clients ou prospects, l’analyse de ce que font ses éditeurs concurrents, les témoignages d’entreprises lean de la région (Perrick anime la communauté lean locale) le poussent à imaginer de nouvelles fonctionnalités.

Un nouveau logiciel, Fissa, fortement inspiré d’Opentime a été mis sur le marché l’an dernier. Il permet de collecter les données du temps de présence à l’aide d’une badgeuse ou d’une interface web ou mobile, et de les incorporer dans la gestion des ressources humaines. Ils mettent aussi au point depuis peu le module Skillofi, qui permettra de gérer des matrices de compétences.

De la gestion de tâches au Kanban

Perrick me montre également le module Kanbans que, pour l’instant, seuls lui et son équipe utilisent. L’idée ici est de proposer une fonctionnalité de gestion de tâches (ce type de logiciel est largement utilisé dans la Tech) mais en lui adjoignant une approche Kanban, une visibilité du lead time et la possibilité de lissage (Heijunka). L’ensemble des tâches à accomplir est donc découpé par kanban, qu’il s’agisse de tests avant mise en production, de maintenance préventive, de certificats à renouveler ou de demandes d’utilisateurs. Le prévisible est programmé (et lissé) à l’avance, l’imprévisible (tickets utilisateurs ou issus de gemba kaizen) est inséré dans le flux.

À chaque kanban est assignée une date de démarrage, et le kanban doit en théorie pouvoir être clos en huit heures. Perrick et l’équipe ont une jauge de maximum quatre kanban par personne par jour, qui tient compte des temps d’attente entre deux actions sur un kanban.

Ces règles de fonctionnement vont donc permettre à un ordonnanceur de lisser l’effort sur l’ensemble de l’équipe et dans le temps (Heijunka). L’outil offre des vues de la charge dans le temps par individu mais aussi une vue globale de l’équipe.

Bien évidemment, si la promesse ne peut être tenue, un Andon se déclenche. Pour Perrick, c’est une opportunité de voir comment mettre en œuvre rapidement des contre-mesures : libérer du temps pour absorber le retard en reculant certaines tâches moins urgentes, apporter de l’aide. Un moyen très visuel d’équilibrer charge et capacité.

Des gemba sur le kaizen chaque semaine

La valeur pour les clients ne peut venir que du développement de l’intelligence individuelle et collective de l’équipe. Perrick anime chaque semaine plusieurs sessions de gemba afin de promouvoir l’exploration de domaines méconnus ou insuffisamment maîtrisés, qu’il s’agisse de code, de requêtes SQL, de design, de SEO ou de marketing. L’idée est de prendre un an pour creuser un sujet technique difficile, explorer de nouveaux champs d’action, avec un leader sur chaque sujet, une fréquence de revue de 3 semaines, et en s’appuyant sur des itérations successives de PDCAs.

Le premier gemba que nous faisons ensemble va d’ailleurs porter sur le marketing, avec Chloé. “Nous continuons à développer et à améliorer notre produit, mais nous avons une vraie difficulté à être vus ou trouvés”, explique Perrick. Chloé porte à ce sujet deux thématiques parallèles de kaizen. D’un côté développer des partenariats pour accroître la visibilité d’Opentime ; et de l’autre, optimiser le SEO du site pour qu’une recherche internet débouche plus facilement sur eux, sans pour autant recourir à une approche payante.

Nous sommes devant le panneau animé par Chloé. La première chose intéressante est la vision sous forme de schéma de ce qu’on cherche à “craquer” : quel partenariat et avec qui ? Avec de gros clients qui les mettent au panel de fournisseurs ? Des éditeurs de logiciels de comptabilité ou de paie avec lesquels Opentime s’interface pour y déverser les données de temps ? Des marketplaces ? Des salons ou des communicants ? Le schéma liste des cibles précises dont certaines, déjà cochées, révèlent la progression de Chloé dans son parcours d’exploration.

Des itérations répétées pour mieux apprendre

Ce qui me frappe, c’est la simplicité de l’approche mise au point : avec cette vision claire de ce qu’on cherche, Chloé a ouvert un puis deux puis plusieurs pages de PDCAs. Chaque ligne est un classique Problème – Cause – Contre mesure – Résultat – Apprentissage – Statut (ouvert ou clos).

Par exemple, si le problème est de trouver le bon contact d’une marketplace (cause : on ne les connaît pas), que la contremesure de recherche a donné un résultat (la marketplace est favorable au partenariat mais il faut fournir toute une documentation technique), Perrick discute de l’apprentissage avec Chloé (il s’avère que la marketplace est encore plus connue du marché cible qu’ils ne le pensaient de prime abord) et il clôt la ligne d’un coup de tampon. Puis il en fait ouvrir une autre à Chloé sur la documentation technique (c’est un problème parce qu’elle n’y connaît rien et qu’elle va devoir trouver de l’aide). Après discussion, la contre-mesure va requérir de travailler avec un des Chefs de Projet de No Parking pour fournir l’information technique, voire valider une interface. Chloé et Perrick s’interdisent d’avoir plus de 4 PDCAs ouverts en même temps.

Mais c’est ici que cela devient encore plus intéressant. Chloé aurait pu sous-traiter la tâche en créant un kanban dans Opentime et attendre qu’un Chef de Projet Technique de l’équipe s’en débrouille. C’est une technique bien connue de notre cerveau qui cherche l’économie d’énergie et tend à évacuer le problème dès lors qu’un autre s’est vu assigner la suite à donner.

L’apprentissage à deux

Chez No Parking, inspirés par le pair programming et les peer reviews, on va plutôt travailler à deux : le chef de projet technique va apporter son savoir technique, Chloé sa connaissance des enjeux de la marketplace et ils vont travailler le point en binôme. Et apprendre ensemble. Chloé va donc devoir négocier le temps et la disponibilité du chef de projet technique (qui a ses propres développements de code ou du kaizen à faire) et mesurer de son côté la difficulté ou le temps que prend sa demande. Une opportunité le cas échéant de mieux la préparer.

Je vois régulièrement Perrick revenir à l’intention initiale (qu’est ce qu’on cherche à faire), et solliciter de Chloé sa propre compréhension du next step, du prochain pas à faire. C’est un vrai parcours d’apprentissage : l’équipe a créé des tokens (des URL spécifiques) pour voir qui arrive et d’où sur leur site Opentime, afin de voir si les partenariats marchent effectivement.

Une semaine réussie exige du temps d’exploration

Perrick a des contraintes de gérant, il faut faire rentrer de nouveaux clients, arriver à les facturer puis à se faire payer : un petit éditeur peine à obtenir de ses plus gros clients que le coût de la licence soit prélevé, il faut négocier et suivre tout un processus d’acceptation et de contrôle, au risque de buter parfois à la dernière minute sur un détail administratif omis. Un travail de fond dont Perrick suit de près les résultats, le cash ainsi collecté finançant le temps passé sur les nouveaux modules en gestation.

Mais Perrick ne conçoit pas de terminer sa semaine sans y avoir aussi inscrit du temps d’exploration, pour lui et pour son équipe. Une semaine réussie pour lui c’est avoir pu 1) explorer (regarder le marché, rencontrer des partenaires, des clients, des prospects, analyser la concurrence, écouter des retours d’expérience lean…), 2) créer de nouveaux clients, 3) facturer, 4) échanger avec au moins deux membres de son équipe sur leur kaizen, qu’il s’agisse de code, de design, de clients ou de marketing. Il le suit même visuellement chaque semaine. Ce takt de l’exploration diffuse dans toute l’équipe et transforme l’intention de progresser en réalité quotidienne.

Nous poursuivons ainsi le gemba avec Perrick. Léa, chargée du design, bosse sur les Cascading Style Sheets (CSS). Elle a déjà repéré et corrigé dans son kaizen précédent un bon nombre de problèmes de design du logiciel et du site, défauts, incohérences… dont une partie vient de l’hétérogénéité des versions de logiciel. Après discussion, Léa, qui sait sur quelle vision cible d’architecture elle veut aller, se donne comme prochaine étape le dessin de l’architecture actuelle des CSS. Elle veut notamment créer une matrice entre fichiers CSS et versions du logiciel, pour voir quel fichier est appelé sur quelle version. C’est à partir du constat précis actuel qu’elle pourra voir comment aller vers la cible.

Quelques bureaux plus loin, Jeff, chef de projet technique, cherche à améliorer la performance du logiciel. Les outils de gestion de temps comportent énormément de données par salarié, par mois, et les services RH sont friands d’extractions historicisées, parfois sur des périodes très longues et ces exports s’avèrent gourmands en ressources.

Laury, également cheffe de projet technique, travaille sur l’application mobile du logiciel, dont personne ne supervisait jusque là la performance. Des sondes envoient désormais des alertes si l’application se met en berne. Laury a un premier apprentissage sur ce kaizen : elle a repéré des copier-coller de code qui s’avèrent dangereux. Plutôt que de corriger chaque endroit individuellement, elle doit remanier l’architecture générale pour éviter ces duplications puis faire évoluer le nœud central.

Et ça marche !

Un signe que toute cette approche fonctionne est qu’il n’y a aucun turnover dans l’équipe, même pour ceux qui ont le plus d’ancienneté (l’entreprise a plus de vingt ans). Il est sans doute plus simple au sein d’une petite équipe de créer de la confiance et de la collaboration, et de s’assurer que tout se passe bien quand le gérant partage le même bureau. Mais différents métiers s’exercent au sein de No Parking, chacun avec un agenda propre, un angle de vue spécifique de la performance. Même à huit, il faut négocier, trouver des compromis, et, clairement, les itérations de PDCAs y contribuent.

Les challenges sur lesquels Perrick les emmène font d’autant plus sens en termes de business, que les résultats se voient : tous les grands comptes ont renouvelé leur contrat sur 2026 (certains sont clients depuis 2006, Perrick travaille de près le principe du Life Long Customer cher à Toyota) et les efforts marketing ont permis de tripler le nombre de leads entrants à budget constant (toujours sans publicité en ligne d’ailleurs). Travailler la confiance par le binômage, offrir des challenges techniques par les itérations de PDCAs, donner du sens, chercher la valeur pour le client, explorer : un beau programme pour cette petite équipe qui réussit.

Catherine Chabiron

Traduction d’un article publié dans Planet-Lean.com le 11 décembre 2025