Coder 10x plus vite : à quoi ça sert vraiment ?

J’ai vu passer ce post sur reddit Pour les devs qui gagnent bcp de temps grâce à l'IA : vous en faites quoi ?

Et je me suis effectivement posé la question. J’ai une réponse de mon côté, que je vais vous partager. Mais je suis bien conscient que mon cas est particulier. Donc je voulais creuser un peu et je me suis rendu compte d’un truc : ce n'est pas gagner du temps qui devrait vous préoccuper. C'est : ça change quoi pour vous ?

Est-ce que vous bossez moins, plus, différemment ?

Quel est l’impact dans une grosse boîte ? Ou pour un(e) freelance ?

Bref, si une personne gagne du temps, à quoi ça lui sert ? 

Un gain de temps discutable ?

Bon déjà, pour être complet sur la question et surtout prendre du recul, une étude récente du METR (Model Evaluation & Threat Research) montre que ce gain de temps ne serait pas si évident que ça. 

L’étude montre que des développeurs expérimentés sur une base de code historique serait 20% plus lent avec l’IA, lié en grande partie aux cycles de relectures. 

Il faut prendre l’étude avec des pincettes puisqu’il s’agit d’un panel de 16 personnes. Il faut aussi comprendre le contexte, on parle de devs experts sur une base de code importante et complexe. 

Je ne vais pas m’attarder sur cette étude parce que je peux aussi en trouver d’autres qui disent l’inverse. Mais je trouvais plus honnête intellectuellement de la citer histoire d’équilibrer le débat et surtout de lui faire prendre de la hauteur.

L’idée ici, c’est qu’on ne va pas partir du principe que forcément l’IA nous fait gagner du temps. Je ne veux pas rentrer dans ce débat. A la place on va faire complètement abstraction de l’IA et juste considérer une hypothèse : 

Imaginons qu’une personne aille 20, 30% plus vite, voire même 10x plus vite pour produire du code, qu’est ce qui se passe ? Si la production logicielle devient moins couteuse, quel est l’impact sur le métier de développeur ? Qu’est-ce qu’on peut faire de ce temps gagné ?

Cette hypothèse est loin d’être débile. Aujourd’hui on se focalise sur l’IA mais le métier a radicalement changé depuis le temps où on devait cabler un ordinateur pour le programmer. On n’a eu de cesse d’améliorer la productivité. Et nos successeurs ne bosseront sans doute pas comme nous. 

Une opportunité pour les créateurs de produit

Je suis un cas particulier donc ma réponse ne s’applique pas à la grande majorité des gens. 

Je bosse à 2 sur un produit récemment créé. J’ai pas de contraintes productivistes, pas de salaire, personne à qui rendre compte.  

Je gère mon temps comme je le veux. Si jamais je finis une tâche en 1h plutôt qu’une semaine, j’ai juste le droit d’arrêter de bosser et faire autre chose. J’ai pas d’obligation d’empiler les heures pour pointer en fin de journée.

Bien sûr j’ai quand même une certaine pression, faut que le produit soit bon et adopté. Je surveille le nombre de nouveaux utilisateurs chaque mois, la croissance du chiffre d’affaires, les retours aussi qu’on me fait par email. Mais justement, pour mon cas, c’est une bonne chose d’avoir du temps supplémentaire.

Je peux répondre aux emails en y passant plus de temps. Je peux faire des analyses plus poussées, sur mon marché et les feedback utilisateurs. 

Bref, je le vie comme une opportunité.

Là où avant le “technical founder” passait tout son temps à coder le produit et vivait la tête dans le guidon avec un gros handicap pour penser long terme sur le produit, gagner du temps me permet de rééquilibrer la balance.

J’adore coder. Mais coder me prenait du temps de cerveau sur la stratégie.

Ce n’est plus le cas.

Je peux passer plus de temps sur le pourquoi, et pas le comment.

Du temps pour améliorer le produit, pas juste le complexifier

Le temps a toujours été une ressource rare dans la construction de logiciel et d’entreprise. Quand je gagne du temps je peux le passer à plein d’autres choses pour le produit, améliorer la documentation utilisateur par exemple, ou améliorer le harnais de test pour m’épargner des futurs problèmes. 

Je peux passer du temps sur des bugs que je vois passer dans les logs ou des petites pétouilles que j’avais vu dans l’interface mais que dans un autre contexte j’aurais repoussé à plus tard.

Vous avez tous en tête le symptôme de ce backlog jira infini et dans lequel on met des petites fiches d’amélioration. Ces fameux “on verra plus tard” qui sont surtout là pour nous donner bonne conscience ou pour satisfaire la personne du support qui nous en a parlé. 

“T’as vu regarde, c’est dans notre TODO list. Bon, faudra 15 ans pour dépiler cette fiche mais c’est dedans…”

Pour moi ça n'existe plus. Les petits soucis comme ça, je les empile par douzaines et le produit progressivement devient meilleur. 

Si on reprend l’analogie financière de la dette technique. A partir du moment où le code me coûte moins cher, le remboursement se fait au fil de l’eau, ce qui diminue le coût de la dette (les intérêts). 

Du temps pour se former

Depuis que j’ai moins de temps à passer sur le code, j’ai pu passer beaucoup plus de temps à réfléchir aux problèmes à résoudre. Et pour ça, j’ai pris plus de temps pour m’éduquer.

Avant j’étais pressé par le temps donc j’étais obligé de faire des raccourcis. Mais récemment j’ai pu me documenter et écrire des articles sur l’état de l’art autour des questions de modérations sur les plateformes de contenu, je me suis penché sur le fonctionnement des attributions de certificats SSL, le fonctionnement des proof of work sur les captcha. J’ai creusé des sujets comme la parité de pouvoir d’achat.

Et puis, aussi surprenant que ça paraisse, j’ai tout simplement lâché le clavier.

Souvent dans mes journées types, je passe du temps loin de l’écran. J’ai amélioré ma technique sur les bouillons pour les ramen, j’ai fait plein de bricolage et j’ai commencé à construire des meubles pour la maison. 

Et paradoxalement, ce temps m’aide aussi à construire mes produits. 

Vous avez déjà remarqué que vous résolviez souvent des problèmes complexes sous la douche ? 

Glander favorise la créativité.

J’ai mis du temps à l’accepter mais laisser son cerveau se reposer. Le laisser incuber une idée et vagabonder pendant qu’on fait autre chose, c’est un excellent stimulant pour résoudre des problèmes. 

Bien sûr, je sais que mon cas est spécifique. Je me vois mal démarrer une séance de menuiserie dans un open space au milieu d’une équipe de dev. Mais pour mon cas, gagner du temps sur du dev, c’est un rééquilibrage global de mes journées et paradoxalement, un travail de meilleure qualité qui est produit. 

Parce que le sujet n’a jamais été “que” de faire du code mais aussi de réfléchir au long terme, ce qui est plus simple quand on a le temps pour le faire.

Maintenant évidemment, je me doute que c’est un peu différent dans un contexte plus traditionnel. Alors je me suis documenté pour voir ce qu’on en disait ailleurs.

Productivité et burnout : le vrai coût

Une des premières réponses provient d’une étude de la Harvard Business Review. L’augmentation de la productivité ne conduirait pas à une réduction du temps de travail, mais à une intensification. 

Le travail deviendrait plus intense pour plusieurs raisons : 

• l’IA supprimerait les pauses cognitives. Et oui, puisqu’il serait plus rapide de démarrer un sujet avec l’IA, on perdrait le moment de pause qui existe normalement au début de chaque projet pendant lequel on se demande comment faire. 
• l’IA gommerait les frontières entre métiers. Je me sentirais plus capable de faire du front, du design, de l’ops, du back, du mobile et donc mon périmètre de travail explose
• La gratification étant plus fréquente, on serait incité à continuer sans arrêt. Si vous faites 10 tickets par jour et que chaque ticket est rapide, pourquoi ne pas faire le 11eme ? Un petit prompt avant de fermer l’écran ?

Sauf que cette intensification vient avec un prix élevé : la fatigue, le burnout, les erreurs (parce que, quand on est fatigué on laisse passer plus de choses).

Je suis tombé sur un article qui parle exactement de ce sujet et qui compare l’IA à un vampire qui drainerait notre énergie. 

L’idée est simple, comme l’IA prend en charge toutes les tâches simples et répétitives, qui servaient autrefois de pause cognitive, il nous reste essentiellement les tâches de haut niveau, les décisions critiques.

Or nous ne sommes pas capables de prendre ce type de décision constamment pendant 8h par jour. C’est beaucoup trop intense.

C’est pour ça que, personnellement, soit je m’éloigne de l’écran une partie de la journée, soit j’y fais des activités plus récréatives : écrire un article (ce qui explique que j’écrive plus qu’avant ^^), ou me former. Et c’est d’ailleurs la recommandation de l’article, il faut trouver un nouvel équilibre.

Je ne sais pas dans quelle mesure l’article est sincère mais c’est ce qui semble être l’approche chez Github. Ils ont utilisé le gain de temps, non pas pour augmenter drastiquement la productivité mais pour d’autres types de tâches, la collaboration, la réflexion. 

Faire plus ≠ Faire mieux

De toute façon, il y a une limite physique à ce que les utilisateurs finaux peuvent encaisser en termes de nouvelles fonctionnalités par jour.

C’est pas parce qu’on peut produire 10x plus de nouvelles features que c’est bénéfique pour l’utilisateur final. 

C’est ce qu’on appelle la loi de Tesler, la loi de conservation de la complexité. Dans un système, il existe une quantité de complexité qu’on ne peut pas réduire. Si on la réduit quelque part, par exemple pour les développeurs qui vont plus vite, elle se répercute ailleurs, pour les utilisateurs qui doivent s’adapter à un logiciel qui évolue beaucoup trop vite. 

On s’expose aussi au risque de “feature fatigue” qui rend les logiciels trop complexes, car trop complets. C’est souvent une bonne chose d’être forcé à faire des choix. 

Bref, ce n’est dans l’intérêt de personne d’augmenter la cadence et il est préférable que les gains de productivité se reflètent davantage dans des features mieux pensées ou une augmentation du travail fait sur la qualité “invisible”. 

Quand la productivité crée l'ennui

Maintenant il y a un scénario qui me semble aussi important à mentionner. Il y a beaucoup de gens qui bossent dans des entreprises où aller plus vite ne changera absolument rien. Parce que ces entreprises luttent davantage contre leur propre inertie que contre un quelconque défi produit. 

J’ai bossé en grosse boite. Et je me rappelle très bien d’une mission en 2003 où coder n'était juste pas le sujet.

Je venais d’un job précédent ou c’était plutôt dynamique. J’étais habitué à un certain rythme. Dans ce nouveau job, on m’a donné un programme à faire. Je l’ai réalisé en 2 jours. Je suis retourné voir mon boss de l’époque. Il m’a dit qu’on en rediscuterait 3 semaines plus tard. En un an, j’ai presque rien produit et c’est sans doute la pire année de ma carrière. 

Le matin t’avais des gens qui passaient pour dire qu’il y aurait des réunions sur tel ou tel sujet et demandait qui voulait participer. Je ne comprenais pas pourquoi tout le monde y allait constamment.

Mais après j’ai compris. C’était pour occuper les journées. 

Si j’avais mis 1h pour faire mon travail plutôt que deux jours, je me serais juste ennuyé plus longtemps. 

Je savais qu’on pouvait faire des burnout. Mais là bas j’ai failli faire un bore out. Et puis j’ai commencé à me former en parallèle sur tout ce que je voulais. J’ai rentabilisé ce temps.

Mais je vous cache pas que j’étais heureux comme pas possible quand la mission s’est arrêté…

Bref, il y a des endroits où coder plus vite, ça ne changera rien. Les pauses café seront juste plus longues…

Freelances : du temps passé à la valeur produite

Maintenant il y a une population pour laquelle je me pose encore pas mal de questions. 

Partons toujours du scénario où le coût du code s’effondre, que deviennent les personnes qui facturent au temps passé ?

On pourrait imaginer qu’une partie de cette population ne va pas forcément crier sur tous les toits qu’elle a terminé son job plus rapidement, puisque ça impliquerait de perdre de l’argent.

Est-ce que c’est tenable sur le long terme, d’autant plus pour un freelance qui travaille dans les locaux du client, donc à la vue de tous ? Dans les grands groupes dont je parlais tout à l’heure, oui certainement. Mais ça ne tiendra jamais dans une entreprise dont les développeurs aussi utilisent les mêmes outils pour aller plus vite.

Et c’est là où je me demande si le forfait, la facturation au résultat, ne pourrait pas devenir plus avantageux que la facturation au temps passé.

Habituellement j’ai plutôt tendance à déconseiller l’engagement de résultat, surtout sur des freelances plus jeunes parce c’est pas si simple que ça de contractualiser correctement et de savoir poser des limites ou tout simplement de savoir estimer un travail avant de le réaliser. 

Mais si l’IA permettait de sécuriser le développement, et de le rendre plus rapide, le forfait pourrait regagner de l’intérêt.

Il ne s’agirait plus de facturer du temps, mais de la valeur. 

Je n’aurais aucune réserve à faire payer une certaine somme pour un travail qui a de la valeur, même si j’y passais seulement 1 ou 2 jours. 

J’ai travaillé pendant 25 ans pour être capable de donner ce résultat en 2 jours. Un client paie votre expérience, et votre capacité à utiliser des outils. Peu importe que vous soyez plus rapide. 

Au pire je pourrais baisser un peu mes prix mais mon risque se paie aussi quand je facture sur un engagement de résultat. 

Malgré tout, je ne sais pas si ce raisonnement tiendra dans la durée. Des concurrents tout aussi bons que moi pourraient s’engager avec plus de clients pour compenser une perte, et donc faire baisser les prix sur un contrat unitairement.

Je suis tombé sur un article qui parle un peu de ça. Sa conclusion étant que les freelances experts vont continuer à s’en sortir mais les besoins vont diminuer. D’autant que leurs clients eux-mêmes vont aussi se mettre à faire du dev si le coût du code diminue.

Une des conclusions de l’article dit par contre que l’IA ne remplacera pas le freelance, mais que **le freelance utilisant l'IA remplacera celui qui ne l'utilise pas. **Et c’est sans doute la leçon la plus importante.

Conclusion

Encore une fois, la question n’était pas, est-ce que l’IA nous rend plus rapide. La vraie question dont je voulais discuter c’était “qu’est ce qu’on fait du temps gagné ?”.

La réponse dépend de votre contexte.

Si vous êtes dans une boîte sclérosée où coder plus vite ne change rien, vous vous ennuierez plus vite. Si vous êtes product-focused et que vous avez la liberté de piloter votre temps, c'est une opportunité incroyable de reprendre du recul sur votre produit. Si vous êtes freelance, c'est peut-être le moment de négocier différemment.

Mais il y a une limite importante : la productivité ne fait sens que si elle crée de la valeur. Débiter 10x plus de features, c'est peut-être pire pour vos utilisateurs. Gagner du temps c’est bien mais ça ne vaut quelque chose que si vous savez quoi en faire.

Bref, il n'existe pas une seule réponse. Mais par contre vous allez peut-être gagner du temps pour trouver cette réponse.