Avant l'IA, j'exécutais. Aujourd'hui, je construis.

Quand mon métier consistait principalement à exécuter

Lorsque j’ai commencé dans le développement front-end, les projets suivaient souvent un schéma assez classique. Les graphistes réalisaient l’ensemble des maquettes — desktop, tablette, mobile. Pour un site de dix pages, cela représentait une trentaine d’écrans à produire, valider puis intégrer.

Ce fonctionnement avait des avantages. Le cadre était clair. Le développeur avait peu de place pour interpréter ou improviser. Si l’intégration respectait fidèlement la maquette, le travail était considéré comme réussi.

Mais avec le recul, je me rends compte qu’une partie du métier me frustrait. J’avais souvent le sentiment d’être un exécutant. Je recevais une maquette. Je reproduisais la maquette. Je passais à la suivante.

Être force de proposition impliquait d’intervenir très tôt dans les discussions de conception, voire de remettre en question des choix déjà validés. Ce n’était ni naturel ni vraiment attendu.

Le projet qui a changé notre manière de fonctionner

Récemment, j’ai travaillé sur le site d’un cabinet d’expertise comptable. Le projet comportait une dizaine de pages aux structures assez différentes. Pourtant, au démarrage, seules deux pages avaient été conçues.

Il y a encore quelques années, cela aurait probablement été perçu comme un problème.

2

maquettes initiales

10

pages à construire

~0

retours design

À partir de ces deux premières pages, j’avais déjà la direction artistique, les composants principaux, les codes visuels et les intentions de design. J’ai donc construit les autres pages directement — en m’appuyant sur l’existant, en proposant mes propres déclinaisons, en développant les interfaces au fur et à mesure.

Puis nous les avons montrées au client.

Voici concrètement ce que ce changement de processus représente :

Étude de cas visuelle

Captures des 2 maquettes initiales et des pages produites — à ajouter

Le temps gagné n’a pas disparu

Quand on parle d’IA, on parle souvent de productivité. Mais je trouve qu’on parle beaucoup moins de ce qu’on fait réellement du temps gagné.

Dans mon cas, ce temps n’a pas été utilisé pour produire davantage. Il a été réinvesti ailleurs. Dans les tests. Dans les animations. Dans les micro-interactions. Dans les détails qui ne figurent pas toujours dans le cahier des charges mais qui contribuent à l’expérience finale.

Une meilleure collaboration pour tout le monde

Ce qui m’a surpris, c’est que je n’ai pas l’impression d’être le seul bénéficiaire de cette évolution.

Le client obtient plus rapidement quelque chose de concret. Il réagit sur un produit réel plutôt que sur une projection. L’agence maîtrise mieux ses budgets. Les designers concentrent leur énergie sur les intentions créatives plutôt que sur la production de variantes proches.

Et de mon côté, je retrouve une dimension du métier qui me manquait. J’aime construire. J’aime réfléchir. J’aime concevoir des interfaces. J’aime proposer des solutions.

La valeur du développeur se déplace

Pendant longtemps, la valeur d’un développeur reposait principalement sur sa capacité à exécuter. Aujourd’hui, je pense que cette valeur se déplace progressivement.

La technique reste essentielle. Mais elle ne suffit plus à elle seule à créer une différence. Ce qui devient précieux, c’est la capacité à comprendre un besoin, prendre du recul, collaborer avec les autres métiers et proposer des solutions pertinentes.

Je ne crois pas que l’IA rende les développeurs inutiles. Je pense qu’elle nous pousse à développer d’autres compétences — comprendre le produit, comprendre les utilisateurs, comprendre les contraintes métiers, comprendre les autres disciplines qui participent à la création d’un projet.

Les pièges existent aussi

Tout n’est pas positif pour autant.

Cette nouvelle façon de travailler apporte aussi son lot de défis. Lorsque les contraintes techniques diminuent, les possibilités augmentent. Et c’est parfois un problème.

Avant, certaines idées étaient rapidement écartées parce qu’elles étaient trop longues à développer ou trop coûteuses à tester. Aujourd’hui, il devient possible d’explorer beaucoup plus de pistes : tester une nouvelle approche, repenser complètement une interface, refaire une architecture ou encore créer un prototype en quelques heures.

Le risque n’est alors plus d’être bloqué techniquement. Le risque est de se disperser.

Je me suis déjà retrouvé à passer davantage de temps à explorer plusieurs solutions qu’à implémenter la première version du problème que je cherchais à résoudre. Cette nouvelle liberté demande donc une autre forme de discipline : savoir quand explorer, savoir quand s’arrêter et surtout savoir quand livrer.

Car même si construire est devenu plus rapide, la valeur ne vient toujours pas du nombre d’idées que l’on teste. Elle vient des problèmes que l’on résout réellement.

Ce qui a réellement changé

Lorsque je regarde mon quotidien aujourd’hui, le plus grand changement n’est finalement pas la vitesse. C’est la place que j’occupe dans la construction des produits.

Avant, j’exécutais davantage. Aujourd’hui, je construis davantage.