On aborde souvent un projet de digitalisation comme un problème d'outillage : quel logiciel, quelle base de données, quelle interface. En réalité, la partie technique est rarement celle qui coince. Ce qui ralentit vraiment un projet, ce sont trois frictions qui reviennent presque à chaque fois.
La résistance au changement n'est pas une résistance à l'outil
Elle est rarement dirigée contre le nouvel outil en tant que tel. Elle est dirigée contre ce que l'outil rend visible, ou contre qui il déplace dans l'organisation informelle. La personne qui maîtrisait un processus manuel depuis des années en tirait une forme d'expertise et de statut — un outil qui rend ce processus transparent et accessible à tous change cet équilibre, même quand personne ne le formule ainsi. Traiter la résistance comme un problème de pédagogie sur l'outil, c'est souvent traiter le mauvais problème.
Les silos entre métiers ne se voient qu'au moment de digitaliser
Deux équipes peuvent travailler ensemble depuis des années sans jamais avoir dû s'accorder sur une définition commune de leurs données — chacune avec son fichier Excel, ses propres colonnes, ses propres conventions implicites. Un projet de digitalisation les oblige, souvent pour la première fois, à se mettre d'accord sur ce qu'est réellement une donnée "validée", un statut "terminé", un flux "complet". Ce travail de convergence est invisible dans le cahier des charges initial, et c'est pourtant lui qui prend le plus de temps.
La lenteur de décision coûte plus cher que le retard qu'elle affiche
Dans une organisation où une décision nécessite plusieurs validations hiérarchiques, le vrai coût n'est pas seulement le nombre de semaines perdues. C'est que l'énergie et l'adhésion de l'équipe projet se dissipent en attendant, et que le contexte a parfois changé au moment où la décision arrive enfin. Un projet qui aurait pu être livré avec l'enthousiasme de son lancement est livré avec l'inertie de sa validation.
Digitaliser un processus cassé ne le répare pas, il l'accélère cassé.
Ce que ça change dans la façon de piloter
Un profil qui comprend à la fois la technique et le métier ne supprime pas ces frictions — elles sont structurelles. Mais il change trois choses concrètes :
- Il prototype au lieu de spécifier. Un outil fonctionnel, même minimal, dépasse en une démonstration ce qu'un cahier des charges met des semaines à faire comprendre — et désamorce une partie de la résistance, parce qu'on discute d'un objet concret, pas d'une abstraction.
- Il traduit sans perte entre métier et technique. Moins d'allers-retours, moins de malentendus qui remontent en fin de projet plutôt qu'au début.
- Il distingue un problème d'outil d'un problème d'organisation. Digitaliser un processus cassé ne le répare pas, il l'accélère cassé. Le repérer tôt évite de construire la mauvaise solution, plus vite.
C'est là, plus que dans la maîtrise d'une techno en particulier, que se joue la valeur ajoutée d'un profil IT sur ce type de projet : réduire le temps entre l'idée et une version qui marche, et le temps entre la friction et sa vraie cause.