Le piège du "c'est unique à nous"
C'est presque toujours la première phrase d'un premier rendez-vous : "Notre situation est un peu particulière." Parfois accompagnée d'une excuse préventive — "Je ne sais pas si vous avez déjà vu ça, parce que chez nous c'est vraiment spécifique." Le dirigeant le croit sincèrement. Ses équipes aussi. Et d'une certaine façon, ils ont raison : la façon dont le problème se manifeste dans leur structure, avec leurs personnes, leur historique, leur secteur, est effectivement unique. Nuancée. Chargée d'un contexte que je ne connaîtrai jamais aussi bien qu'eux.
Mais le problème sous-jacent, lui, n'est presque jamais unique.
Derrière "on perd du temps à ressaisir des infos partout", il y a un pattern. Derrière "quand notre commercial part, on perd le client", il y en a un autre. Derrière "on a acheté le logiciel mais personne ne l'utilise vraiment" ou "on fait les factures en fin de mois parce qu'on n'a pas le temps avant", ce sont des patterns que j'ai vus se répéter — avec des noms différents, dans des secteurs différents, mais avec une logique de fond identique.
Ce n'est pas un jugement. C'est une observation utile. Parce que si le problème est un pattern, alors la méthode de résolution l'est aussi. Et si la méthode est documentée, elle devient transmissible. C'est à ça que sert ce blog.
Le pattern : qu'est-ce que c'est concrètement ?
Un pattern, dans ce contexte, c'est une structure de problème qui se répète dans des environnements différents avec des mécanismes similaires et des causes profondes comparables. Ce n'est pas un template à appliquer à l'aveugle — c'est un modèle de compréhension. Une grille qui dit : si tu vois ces symptômes, voilà ce qui se passe probablement en dessous, et voilà les leviers qui ont fonctionné ailleurs.
Ce qui distingue le conseil terrain du conseil théorique, c'est précisément la capacité à reconnaître un pattern dans une situation qui se présente comme unique. Ça demande du recul, de la mémoire des missions précédentes, et une discipline de documentation. Pas une heure passée à tout écrire après chaque réunion — mais une habitude de formalisation : quel était le problème présenté, quel était le problème réel, quelle décision a été prise, qu'est-ce qui a fonctionné, qu'est-ce qui n'a pas tenu.
Ce que ce blog n'est pas
Ces articles ne sont pas du contenu marketing. Ils ne vendent pas une offre. Ils documentent des méthodes de résolution issues du terrain. Si vous vous reconnaissez dans un pattern, c'est que vous pouvez en tirer quelque chose — que vous fassiez appel à ComiPi ou non.
Je ne prétends pas avoir résolu tous les patterns. Certains m'ont résisté. D'autres ont été résolus en partie, avec des résultats satisfaisants mais pas parfaits. Et dans chaque structure, il y a des nuances que la documentation ne capturera jamais complètement : la personnalité du dirigeant, la culture d'équipe, le rapport à l'outil, l'histoire de la boîte. Ces nuances comptent. Mais elles ne doivent pas empêcher de capitaliser sur ce qui se répète.
Quatre patterns observés sur le terrain
Ce qui suit, ce sont des cas plausibles — composites, anonymisés, construits à partir de situations réelles mais suffisamment transformés pour ne pas être attribuables. Ils sont flaggés comme tels. L'important n'est pas l'anecdote : c'est la structure du problème.
Le pattern "double saisie"
Une PME de services industriels. La commerciale saisit chaque affaire dans un tableau Excel de suivi qu'elle a elle-même conçu il y a quatre ans. Ce tableau alimente un email récapitulatif hebdomadaire envoyé au dirigeant. En parallèle, la même affaire est saisie dans le logiciel métier de la société — parce que le logiciel génère les bons de commande et les factures. Et en parallèle encore, certaines infos sont copiées-collées dans un fil de messagerie d'équipe. En cas de modification sur une affaire — un report de date, un changement de volume — il faut penser à mettre à jour les trois. Personne ne le fait systématiquement. Les divergences s'accumulent. Lors d'une réunion mensuelle, la commerciale et le responsable opérationnel se retrouvent avec deux versions différentes du carnet de commandes.
Ce pattern touche toutes les structures qui ont fait évoluer leurs outils sans jamais revoir leur flux d'information. L'Excel de suivi datait d'avant le logiciel métier. Le logiciel métier est arrivé pour la comptabilité, pas pour le suivi commercial. La messagerie d'équipe est venue encore après, pour la mobilité. Chacun a répondu à un besoin réel. Personne n'a pensé à supprimer les étapes précédentes.
La résolution ne passe pas par "choisir le bon outil". Elle passe par cartographier le flux d'information réel, identifier la source de vérité unique pour chaque type de donnée, et éliminer les redondances. Après, peu importe l'outil.
Le pattern "le commercial a tout dans sa tête"
Un distributeur BtoB, dix salariés. Leur meilleur commercial — présent depuis neuf ans — connaît chaque client par son prénom. Il sait que le responsable des achats chez tel client n'aime pas les relances le vendredi. Il sait que l'autre structure a eu un gros désaccord avec un prestataire concurrent l'année dernière et qu'il ne faut pas en parler. Il sait quelles remises sont acceptables sans dépasser un seuil invisible qui ferait tiquer la direction. Tout ça vit dans sa tête. Rien n'est dans le CRM — parce que le CRM, "c'est lourd à remplir et de toute façon personne ne lit ce que j'y mets". Quand il prend deux semaines de congé, les relances partent n'importe comment. Quand il annonce qu'il envisage de changer de poste, la direction réalise soudainement que le risque client est énorme.
Ce pattern ne vient pas d'une mauvaise volonté du commercial. Il vient d'un outil CRM mal conçu pour l'usage terrain, et d'un management qui n'a jamais créé les conditions pour que la capitalisation des connaissances soit perçue comme utile à celui qui la fait — et pas seulement à l'organisation.
La résolution commence par là : rendre la saisie utile à celui qui saisit. Un CRM qui aide à préparer le prochain appel, à ne pas oublier une relance, à reprendre le fil après les vacances — ça, les commerciaux remplissent. Un CRM qui sert uniquement au reporting de la direction, non.
Le pattern "on a acheté le SaaS, personne ne l'utilise"
Une association de taille intermédiaire — une vingtaine de salariés, des bénévoles réguliers. Le directeur revient d'une conférence enthousiaste : il a vu une démo d'un outil de gestion de projet en ligne. Abonnement pris, licences distribuées. Trois mois après, quatre personnes sur vingt-cinq l'utilisent vraiment. Les autres continuent avec leurs emails et leurs tableaux Excel. L'outil est bon — vraiment. Mais il a été déployé sans formation, sans qu'on explique pourquoi il remplace quelque chose que les équipes faisaient déjà, et sans qu'on gère le fait que certains bénévoles n'ont pas d'ordinateur à la maison.
Ce pattern est peut-être le plus universel. Il touche toutes les tailles de structure, tous les secteurs. L'outil n'est jamais le problème. L'adhésion est le problème. Et l'adhésion ne se décrète pas — elle se prépare.
Ce que j'ai appris en accompagnant ces situations : le plus important n'est pas le choix de l'outil, c'est l'ordre dans lequel on fait les choses. D'abord comprendre le quotidien de ceux qui vont l'utiliser. Ensuite expliquer ce que l'outil va changer dans ce quotidien — positivement. Ensuite former. Ensuite laisser du temps. Seulement après : mesurer l'adoption. Pas avant.
Le pattern "la facture, on la fait en fin de mois"
Une TPE de prestation de services. Deux associés, quatre collaborateurs. La facturation, c'est toujours pour "quand on a le temps". Concrètement : les bons de livraison s'accumulent sur le bureau du gérant. En fin de mois, en général le 28 ou le 29, il se réserve une demi-journée pour tout rentrer et envoyer les factures. Problème : certains clients ont des délais de paiement à 30 jours à compter de la réception de la facture. Une facture envoyée le 29 ne sera réglée qu'à la fin du mois suivant. Sur douze mois, ça fait douze demi-journées perdues, et un décalage de trésorerie chronique que le gérant compense avec sa ligne de découvert — qu'il présente comme "normale pour une boîte de notre taille".
Ce n'est pas une fatalité. C'est un process qui n'a jamais été pensé comme tel. La facturation immédiate à la livraison — ou à l'achèvement d'une mission — n'est pas plus compliquée. Elle demande juste un déclencheur différent et un outil qui ne rende pas la saisie pénible. Quand on règle ça, le découvert se réduit sans que la trésorerie ait structurellement changé.
Comment ComiPi documente les patterns : quatre étapes
Quand je termine une mission, l'objectif n'est pas simplement que le problème soit résolu. C'est que la méthode de résolution soit transmissible — à l'équipe qui reprend, à la structure qui grandit, et, plus généralement, à d'autres structures qui rencontreront le même pattern.
Cette discipline de documentation n'est pas naturelle. Elle demande du temps que les équipes n'ont pas envie de prendre immédiatement après avoir résolu un problème. Mais c'est là que se crée la vraie valeur à long terme. Voilà comment je structure ça :
- Nommer le problème présenté et le problème réel. Ce que le client dit au départ ("on manque de visibilité sur nos affaires") et ce que l'analyse révèle ("les données vivent dans trois endroits différents sans source de vérité") sont rarement identiques. Documenter les deux, c'est documenter le trajet de compréhension — et c'est ça qui est utile à la prochaine structure qui dira la même première phrase.
- Cartographier le flux d'information réel, pas théorique. Pas l'organigramme. Pas la façon dont "ça devrait fonctionner". La façon dont ça fonctionne vraiment — qui envoie quoi à qui, à quel moment, dans quel outil, et ce qui se perd en chemin. C'est le travail le plus lent et le plus précieux.
- Décider et tester progressivement. La mise en production n'est jamais un grand soir. C'est une séquence de petits changements testés en conditions réelles, avec les équipes, ajustés selon ce qui se passe. Documenter les décisions prises, les alternatives écartées, et pourquoi — c'est ce qui permet de ne pas refaire les mêmes erreurs un an plus tard quand quelqu'un voudra "améliorer" ce qui a été mis en place.
- Transmettre, pas juste livrer. L'objectif d'une mission ComiPi n'est pas que la structure dépende de ComiPi dans trois ans. C'est l'inverse : qu'elle comprenne ce qu'elle a mis en place, pourquoi chaque choix a été fait, et comment le faire évoluer sans avoir besoin de tout reconstruire. La documentation n'est pas un livrable annexe — elle fait partie du travail.
Ce processus produit quelque chose de précis : une description structurée du pattern, de ses causes, des leviers qui ont fonctionné, et des points de vigilance pour la suite. C'est ce que j'ai dans mes dossiers de mission. Et c'est ce que ce blog publie — de façon anonymisée, généralisée, utile.
Pourquoi ce blog est un catalogue de patterns, pas un outil marketing
Je pourrais écrire des articles sur les tendances du marché, les nouvelles technologies, les grandes transformations à venir. Ce n'est pas ce que je fais ici — en tout cas pas comme point de départ.
Ce que j'écris, ce sont des patterns. Des situations que j'ai rencontrées, analysées, travaillées. Des méthodes qui ont fonctionné — et parfois des variantes qui n'ont pas tenu, avec l'explication de pourquoi. L'article sur Dolibarr moche et app UX documente un arbitrage technique que j'ai fait plusieurs fois, avec des raisons claires et des limites assumées. L'article sur le management vertical qui bloque encore en 2026 documente un pattern organisationnel que je vois dans presque toutes les structures que j'accompagne. L'article sur la valeur réplicable à l'international documente quelque chose de plus profond : le fait qu'un problème résolu peut, avec la bonne documentation, devenir un outil pour quelqu'un à l'autre bout du monde qui n'a aucun lien avec la structure qui l'a résolu en premier.
Ces articles ne sont pas là pour vous convaincre de travailler avec ComiPi. Ils sont là pour que vous puissiez reconnaître votre propre pattern — et commencer à y travailler, avec ou sans moi. Si au passage vous vous dites qu'avoir quelqu'un qui a déjà résolu ça pourrait accélérer les choses, c'est bien. Mais ce n'est pas la condition pour que l'article ait de la valeur.
Un pattern documenté, c'est de la valeur diffusée
Si ce blog documente cinquante patterns au fil des années, et que chaque article aide dix PME à comprendre ce qui leur arrive et à ne pas réinventer la roue — c'est cinquante fois dix situations de travail améliorées, sans que ComiPi soit nécessairement impliqué dans chacune. C'est exactement ce que j'explique dans le manifeste : un problème résolu n'est jamais uniquement le sien. La valeur se multiplie quand elle est documentée et partagée.
Reconnaître son propre pattern
Si vous avez lu cet article, il y a de bonnes chances qu'un des quatre patterns décrits vous ait rappelé quelque chose. Peut-être pas exactement — peut-être une variante, une version atténuée, ou au contraire une situation encore plus critique. C'est normal : les patterns ne sont pas des cases à cocher, ce sont des structures de problème à reconnaître.
La question utile n'est pas "est-ce que mon problème ressemble exactement à l'un de ceux-là ?". La question utile est : est-ce que le mécanisme sous-jacent est comparable ? Est-ce que les causes profondes se ressemblent ? Est-ce que les leviers qui ont fonctionné ailleurs pourraient fonctionner ici ?
Chaque structure a ses nuances. Je ne prétends pas qu'un pattern documenté se transpose sans adaptation. Mais partir de quelque chose qui a fonctionné ailleurs, comprendre pourquoi, et adapter — c'est infiniment plus efficace que recommencer de zéro en croyant que votre problème est unique.
C'est pour ça que j'écris. Pas pour documenter ce que ComiPi fait. Pour documenter ce que les problèmes ont en commun — et ce que leurs solutions ont appris.
Sur la même ligne éditoriale
- Le manifeste ComiPi : 1999 → 2026La conviction de départ : l'entreprise, c'est de l'information qui circule. Tout le reste suit.
- Valeur réplicable : pourquoi la souveraineté technique ne s'arrête pas à la FranceUn problème résolu, documenté, reproductible — c'est de la valeur diffusée bien au-delà de la structure qui l'a résolu.
- Dolibarr moche + app UX : l'architecture qui tient en 2026Un exemple concret d'arbitrage technique documenté — et les raisons qui l'ont motivé.
- Pourquoi le management vertical bloque encore en 2026Le pattern organisationnel le plus fréquent — et le moins souvent nommé clairement.
Vous reconnaissez un de ces patterns ?
Parlons-en.
Si un de ces patterns décrit quelque chose que vous vivez — ou que vous avez du mal à nommer clairement — on peut regarder ça ensemble, sans engagement.
La suite du catalogue
Le blog ComiPi
D'autres patterns documentés, des arbitrages techniques, des cas clients. Pas de newsletter hebdomadaire — des articles quand il y a quelque chose à dire.