Les outils évoluent. Les bonnes décisions restent.

Nous parlons beaucoup de vitesse. Pas assez du résultat.

Depuis quelques mois, les démonstrations se succèdent. Créer un site en quelques heures. Développer un SaaS en un week-end. Générer une application à partir de quelques instructions.

C’est impressionnant.

Mais un site développé en quelques heures répond-il au besoin de ses utilisateurs ? Une application générée rapidement est-elle maintenable, sécurisée et capable d’évoluer ? La fonctionnalité produite était-elle seulement nécessaire ?

La capacité à fabriquer quelque chose rapidement ne dit finalement pas grand-chose de sa pertinence.

C’est une distinction importante, parce qu’elle touche directement à notre métier. Le code n’est pas le projet. C’est l’un des moyens de le réaliser.

Le vrai travail commence avant d’ouvrir son éditeur de code

Lorsqu’un client nous contacte, il ne nous demande pas réellement d’écrire du code. Il nous demande de résoudre un problème.

Avant de parler WordPress, React, application mobile ou intelligence artificielle, il faut comprendre un métier, un contexte, des contraintes et des utilisateurs. Pourquoi ce projet existe-t-il ? À qui doit-il rendre service ? Quelle place prendra-t-il dans l’organisation ? Comment devra-t-il évoluer dans deux, cinq ou dix ans ?

C’est aussi pour cette raison qu’il nous arrive de déconseiller une application mobile, de remettre en question une fonctionnalité demandée ou de proposer une solution plus simple que celle imaginée initialement.

Parfois, la meilleure décision technique consiste à ne pas développer quelque chose. Nicolas a d’ailleurs un dicton pour ça : « Il est urgent de ne rien faire ».

Ce travail est moins spectaculaire qu’une démonstration générant une application en quelques minutes. Il est aussi beaucoup plus difficile à automatiser, parce qu’il dépend du contexte, de l’expérience et de la capacité à arbitrer entre plusieurs solutions qui peuvent toutes sembler valables.

C’est probablement là que notre métier évolue le plus. À mesure que produire devient plus facile, savoir quoi produire, pourquoi et comment devient encore plus important.

Le risque n’est pas seulement de produire trop vite

Une autre évolution nous interroge : l’uniformisation.

On la remarque déjà dans les contenus et les images générés. Les mêmes formulations reviennent, les mêmes compositions, les mêmes codes graphiques, les mêmes manières de présenter une idée.

Mais ce phénomène ne concerne pas uniquement la communication.

En conception numérique aussi, nous pouvons très vite nous retrouver avec les mêmes interfaces, les mêmes parcours, les mêmes architectures ou les mêmes réponses techniques. C’est assez logique : les outils apprennent à partir de ce qui existe et proposent naturellement les solutions les plus probables.

Or notre travail consiste parfois précisément à ne pas choisir la solution la plus évidente.

Un métier particulier peut nécessiter un parcours inhabituel. Une contrainte terrain peut remettre en cause un standard UX parfaitement établi. Une organisation peut avoir intérêt à conserver une technologie moins récente mais parfaitement maîtrisée plutôt qu’à adopter le dernier framework à la mode.

L’expérience sert aussi à cela : savoir quand appliquer les bonnes pratiques et quand le contexte justifie de s’en écarter.

L’intelligence artificielle peut proposer dix solutions en quelques secondes. Elle rend donc notre capacité à les comparer, les questionner et choisir la bonne encore plus importante.

Gagner du temps ne suffit pas

Nous continuerons à utiliser l’intelligence artificielle. Probablement de plus en plus.

Comme nous avons adopté de nouveaux frameworks, de nouveaux outils de conception ou de nouvelles méthodes de travail au fil des années. Notre métier évolue depuis toujours et il continuera à le faire.

Mais si ces outils nous permettent de produire deux fois plus vite, la meilleure utilisation de ce temps gagné n’est peut-être pas de produire immédiatement deux fois plus.

Nous pouvons aussi l’utiliser pour mieux comprendre un métier. Échanger davantage avec les utilisateurs. Tester une hypothèse avant de la développer. Challenger une demande. Explorer plusieurs solutions. Documenter ce que nous construisons. Anticiper ce qui devra être maintenu demain.

Bref, consacrer davantage de temps à ce que les outils ne décident pas à notre place.

Parce que la technologie utilisée pour construire un projet changera probablement plusieurs fois au cours de sa vie.

Les décisions prises au départ, elles, peuvent laisser des traces pendant des années.