Ce que 20 ans en TI m'ont appris sur la création de produits numériques
Je n'avais pas prévu de devenir concepteur de produits numériques. J'avais prévu d'être bon dans mon travail, quel que soit ce travail à un moment donné. En 20 ans, ce travail a beaucoup changé — analyste, spécialiste de migration de données, directeur TI, consultant ERP, gestionnaire CRM. Des titres différents, des industries différentes, des problèmes différents.
Mais le fil conducteur a toujours été le même : comment prendre quelque chose de brisé ou de manquant et le faire fonctionner ?
On apprend plus de l'échec que du succès
Au début de ma carrière chez Accenture, j'ai travaillé sur de grandes implantations SAP pour des entreprises comme Rio Tinto et Alstom. C'étaient des projets colossaux, coûteux, à enjeux élevés. Le genre où une mauvaise migration de données ne cause pas qu'un bogue : elle arrête une chaîne de production.
J'ai appris vite que dans des environnements comme ceux-là, avoir raison ne suffit pas. Il faut être clair, documenté, et avoir deux longueurs d'avance sur le problème. J'ai aussi appris que même les systèmes d'entreprise les plus sophistiqués échouent quand les humains qui s'en servent ne leur font pas confiance.
Cette leçon m'est restée.
La mentalité de joueur-entraîneur
À un moment de ma carrière, je suis devenu gestionnaire. Et j'ai remarqué quelque chose : beaucoup de gestionnaires cessent de faire le vrai travail. Ils délèguent, ils révisent, ils approuvent. Ils perdent le contact avec les détails.
J'ai refusé que ça m'arrive.
J'ai gardé les mains dans le travail technique même quand mon titre disait que je n'aurais pas eu à le faire. Pas parce que je ne faisais pas confiance à mes équipes, mais parce que je crois qu'on ne peut pas diriger un travail technique qu'on ne comprend pas. On prend de meilleures décisions quand on a mis les mains à la pâte récemment. On pose de meilleures questions. On repère les problèmes plus tôt.
Cette approche de joueur-entraîneur, je l'apporte à chaque projet aujourd'hui.
Le fossé dont personne ne parle
Il y a un fossé énorme entre ce que les outils d'entreprise promettent et ce que les plus petites organisations arrivent réellement à en tirer.
Les grands fournisseurs vendent le rêve. Puis ils partent. Et l'organisation se retrouve coincée avec un système que personne ne comprend tout à fait, une documentation déjà périmée, et un contrat de soutien qui coûte plus cher que ce qu'il rapporte.
La situation du transport en commun à la RMWB en était un parfait exemple. Un système que plus personne ne pouvait utiliser, une expertise partie par la porte, et 125 000 résidents qui dépendaient des autobus à l'heure.
Nous avons construit un pont. Ça a fonctionné. La municipalité a continué de rouler.
Ce que je sais maintenant et que j'aurais aimé savoir plus tôt
La portée, c'est tout. Chaque projet qui a déraillé avait une chose en commun : la portée n'a pas été maîtrisée assez tôt. Pas parce que les gens étaient incompétents, mais parce que personne ne voulait être celui qui dit non. J'ai appris à dire non tôt et clairement. Ça sauve tout le monde.
Les utilisateurs sont le produit. On peut bâtir un logiciel techniquement parfait que personne n'adopte. L'adoption vient du fait d'impliquer les utilisateurs tôt, de bâtir ce dont ils ont réellement besoin, et de faire en sorte que l'outil ait sa place dans leur flux de travail.
La vitesse compte plus que la perfection. Un bon produit livré en deux semaines bat un produit parfait livré en six mois. Les marchés bougent, les priorités changent, les budgets disparaissent. Mettez quelque chose de réel devant de vrais utilisateurs le plus vite possible et itérez à partir de là.
La technologie est un moyen, pas une fin. J'ai travaillé avec des entreprises qui couraient après chaque nouvel outil et plateforme, toujours à la recherche de la technologie qui réglerait leurs problèmes. La technologie n'a jamais été le problème. C'était la clarté de la réflexion sur le problème.
Pourquoi j'ai lancé akafal.com
Après 20 ans, j'ai atteint un point où je voulais faire le travail que j'aime vraiment, sans la politique, la bureaucratie et les paliers d'approbation qui ralentissent tout dans les grandes organisations.
J'ai lancé akafal.com parce que je crois que les entreprises sérieuses méritent des produits numériques sérieux, bâtis par quelqu'un qui en a assez vu pour savoir ce qui compte vraiment.
Pas une agence avec une équipe de vente et un portfolio de développeurs juniors. Une personne. Avec un bilan. Qui répond à vos messages et livre votre produit.
Vingt ans m'ont appris beaucoup. Le plus important : ce n'est jamais vraiment une question de technologie. C'est une question de comprendre le problème assez bien pour le régler simplement.
Un projet qui vaut la peine d'être construit ?
Si quelque chose ici a résonné, la prochaine étape est un court appel — trente minutes pour valider l'idée et voir si je suis la bonne personne pour la livrer.