LinkedIn·Tuesday, 25 August 2026·16h ago

« Je veux que tous les workflows soient éditables, de bout en bout. » Je demande pourquoi. La réponse n'a rien à voir avec un besoin…

Khalid Yagoubi

Je conçois le cœur et le cerveau digital des PME : CRM/ERP sur mesure, automatisation, MVP SaaS et AI Agents | Fondateur KERN-IT | Fractional CTO/CPO

« Je veux que tous les workflows soient éditables, de bout en bout. » Je demande pourquoi. La réponse n'a rien à voir avec un besoin actuel. Dans l'ancien outil, déplacer une étape de validation nécessitait un ticket et trois semaines d'attente. Je lis des cahiers des charges toute l'annee et je retrouve souvent ce mécanisme : on ne décrit pas seulement ce qu'on veut construire, on essaie surtout de ne pas revivre ce qui nous a frustrés. Le problème, c'est qu'on finit par concevoir l'exact opposé de l'ancien système. Un changement compliqué devient un moteur de règles entièrement paramétrable. Une panne un vendredi soir devient une exigence de disponibilité à 99,99 %. Une mauvaise expérience avec un prestataire pousse à vouloir tout reprendre en interne. Ce sont des réactions compréhensibles. Mais elles peuvent coûter très très cher et vous devenez parfois responsable de trop de choses. Une entreprise ne modifie généralement pas ses processus assez souvent pour que tout doive être configurable. Elle a surtout besoin que les bons endroits puissent évoluer sans devoir reconstruire l'ensemble. Malgré cela, on consacre parfois une grosse partie du budget à une souplesse qui servira deux ou trois fois. Et le jour où le processus change vraiment, deux ans plus tard, personne ne se souvient du fonctionnement du moteur de règles. On finit donc par ouvrir un ticket. Il arrive aussi que le problème ne soit pas l'outil. Une décision n'a jamais été prise. Le périmètre n'a pas été clairement défini. Deux équipes travaillent différemment sans avoir mis leurs pratiques à plat. Mais remplacer un logiciel est une action visible, avec un budget et un planning. Organiser les conversations nécessaires l'est beaucoup moins. On remplace alors l'outil sans régler ce qui bloquait réellement. J'ai vu des équipes changer plusieurs fois de logiciel et continuer à formuler les memes reproches. Ce qui les gênait n'avait jamais été discuté, décidé ou correctement paramétré. A plus grande échelle, cette même frustration fait naître des entreprises. Quelqu'un utilise un logiciel tous les jours, le trouve mal fichu, et se dit qu'il fera mieux. Parfois c'est vrai, et de très bons produits naissent comme ça. Souvent, on réinvente la roue en moins bien : en face, quarante développeurs servent dix mille usages qu'on ne voit pas depuis le sien. Parfois une société qui existe parce que son fondateur était agacé, sans avoir jamais trouvé à qui elle servait vraiment. Une frustration ne devrait pas, à elle seule, dicter l'architecture du prochain système. Elle indique souvent très bien l'endroit où ça coince. Elle explique moins bien ce qu'il faut construire à la place. Quand je relis une demande, j'essaie donc de distinguer deux choses : - Qu'est-ce que l'entreprise ne veut plus revivre ? - Et qu'est-ce qu'elle veut réellement rendre possible ? Avez-vous déjà surdimensionné un projet pour compenser les limites de l'ancien outil ? #process #tools #software