Avant, votre métier s'adaptait au logiciel.Maintenant, c'est l'inverse.

Il fut un temps, pas si lointain, où s'équiper d'un logiciel métier ressemblait à un chantier. On montait une grosse infrastructure, on empilait des logiciels lourds et propriétaires, et on lançait une petite armée de développeurs pour tordre tout ça jusqu'à ce que ça colle, à peu près, à votre façon de travailler. Des mois de spécifications, un budget qui gonfle, un cahier des charges figé bien avant que le premier utilisateur ait touché quoi que ce soit.

Le résultat, on le connaît. Cher. Lent. Surdimensionné. Et souvent déjà en retard le jour de la livraison, parce que le métier, lui, n'avait pas attendu.

Bien sûr, il y avait les précurseurs. Ceux qui parlaient déjà d'agile, qui prototypaient, qui itéraient. Et l'agile, c'est beau, c'est juste. Mais on en a tellement vendu, à tire-larigot, qu'on en a fait un produit de plus sur l'étagère : une surcouche de méthode et de rituels dont le client ne percevait pas vraiment les bénéfices. Alors que oui, c'est pourtant par là qu'il faudrait commencer. Un design sprint bien mené évite la moitié des problèmes d'après. Mais itérer coûtait, et cette exploration-là, le client ne voulait pas la payer. Alors on coupait.

Pendant vingt ans, on avait pris le problème à l'envers.

Je n'ai pas lu ça dans une étude, je l'ai vu de près. On n'avait que deux options, mauvaises toutes les deux. Soit on prenait un produit déjà tout fait et on pliait l'entreprise pour la faire entrer dans ses cases : on changeait ses process, on formait les équipes à contre-emploi, on appelait ça une « transformation », alors que c'était une capitulation devant la rigidité de la machine. Soit on créait la case de zéro, du sur-mesure taillé pour soi, mais là c'était une fortune : il fallait tout écrire à la main, et cette lenteur passait même pour un gage de sérieux. Plus c'était long et cher, plus ça avait l'air solide.

Dans les deux cas, la friction n'a jamais été une garantie de qualité. C'était juste de la friction.

Aujourd'hui, la donne a changé, et pas qu'un peu. On ne commande plus une usine à gaz : on met en place des outils et des workflows qui se construisent en marchant. On sort une première version, on la met entre les mains des vraies personnes, on regarde où ça coince, et on ajuste. Et pour une fois, personne ne fait de gros yeux, ni les développeurs, ni ceux qui pilotent le projet. Pas de malaise qui s'installe, pas d'avenant à négocier dans la douleur : l'ajustement est simple, alors on le fait. Le logiciel évolue avec les tests, avec les usages réels, avec les problèmes que seuls les utilisateurs font remonter. Agile, pour de vrai, du premier jour jusqu'à l'usage quotidien, et pas seulement sur le slide d'un consultant.

Échouer vite coûte moins cher qu'avoir raison trop tard.

C'est là que l'IA change tout. Pas en bradant le travail, mais en retirant la peur qui bloquait tout : celle du coût de la technique. On ne commence plus par calculer combien de développeurs, combien de semaines, combien ça va coûter, avant même d'avoir tranché quoi que ce soit. Cette question, longtemps la plus paralysante, passe au second plan. Et toute l'énergie qu'on brûlait à redouter la facture, on peut enfin la remettre là où se joue la vraie valeur : la réflexion et la stratégie. L'agile n'avait pas besoin d'être réinventé, juste qu'on cesse d'avoir peur de le pratiquer.

Et ce sont justement les disciplines qu'on avait fini par prendre de haut qui reprennent toute leur valeur. L'agilité, le design thinking, la gestion de projet : non plus des rituels vendus au forfait, mais l'art de poser les bonnes questions, d'écouter les usages et de faire les bons arbitrages. Ce qui, hier, ralentissait le projet devient aujourd'hui ce qui lui donne sa direction.

Et c'est là que le vrai sujet apparaît. Quand construire l'outil devient accessible, quand ce n'est plus la partie difficile, la question se déplace. Elle n'est plus « combien de développeurs et combien de mois ». Elle devient « quel est, précisément, le bon problème à résoudre ». Savoir lire son propre métier, repérer le geste qui fait perdre trois heures par jour, distinguer ce qui mérite d'être outillé de ce qui doit rester humain : voilà la ressource rare. L'exécution, l'IA s'en charge. Le jugement, non.

C'est exactement comme ça que nous travaillons. L'IA nous permet d'aller vite là où la vitesse compte : prototyper, tester une idée, sortir un premier workflow en quelques jours plutôt qu'en quelques mois. Mais ce qui fait la différence, ce n'est pas la vitesse, c'est de savoir quoi construire, et de trancher quand l'outil propose une facilité qui, sur le terrain, serait une bêtise. L'IA accélère, l'expertise garantit.

Alors la vraie question n'est plus technique. Elle est pour vous.

Qu'est-ce qui, dans votre métier, vous coûte le plus de temps pour le moins de valeur ? Cette tâche que tout le monde déteste, ce fichier Excel devenu ingérable, ce process qui tient par habitude, par miracle, ou par la fameuse phrase « on a toujours fait comme ça » ? Vous ne voyez pas encore par où commencer ? C'est normal, et c'est même le meilleur endroit d'où partir.

Concrètement, ça se passe en quatre temps :

Pas de tunnel de six mois, pas de cahier des charges gravé dans le marbre. On part de votre métier, et on construit l'outil autour de lui.

Le bon outil ne vous change plus. Il vous ressemble.