FISSURE - Quand l’IA écrit le code, que reste-t-il aux développeurs ? avec Les Fabricants

Ces deux dernières années, on a vu beaucoup d’agences web et mobile

qui

passent en redressement, voire qui passent en liquidation.

Et ça, en particulier ici, à Lille,

où le secteur est très exposé au retail,

qui ne vit pas très bien, forcément, la période inflationniste,

la crise financière dans laquelle on est depuis 2023,

avec la guerre en Ukraine en particulier.

Et dans les agences du Nord,

il y en a une qui tient bien en particulier : c’est Les Fabricants.

Eux, ils ont même racheté un concurrent à la barre récemment.

Ils continuent de recruter, continuent de se développer.

Et c’est pour ça que j’avais envie de comprendre :

c’est quoi, leur recette ? Surtout que récemment,

ils ont pris la parole sur

l’agentic coding, avec notamment le steer coding. Et avant, eux,

c’était une agence qui était plutôt identifiée sur le no-code.

Aujourd’hui, ils s’identifient sur l’agentique. Donc je voulais comprendre :

vu que c’est une agence qui a une bonne recette pour faire le métier d’agence

web ou d’agence mobile en 2026, comment l’agentique s’intègre dans leur recette ?

Et c’est Ben, le CTO et fondateur de l’agence,

qui a pris le temps de répondre aux questions.

Il était accompagné du dev qui s’appelle Alexis.

Vous allez voir dans la dynamique : Ben, c’est celui qui lance des idées.

Alexis, c’est celui qui les rend solides.

Et dans l’entretien, ça s’entend, honnêtement :

Ben va dire quelque chose et Alexis va le structurer ensuite.

Franchement, c’est un chouette entretien. Écoutez,

ils portent une vision de ce qu’est le futur du métier de développeur,

alors qu’aujourd’hui, notre métier, il a changé.

Si vous, vous aimiez avant faire du code,

aujourd’hui, plus personne n’est intéressé par le fait de faire du code.

Et pourtant, on est encore développeur et on va tous devoir

trouver une raison ou une nouvelle vision de ce métier-là.

Et Ben et Alexis en apportent une qui est très forte, qui a une opinion très…

Je pense que cet entretien le rend bien visible.

Alors, ce format-là, c’est un format qu’on appelle Fissure.

C’est-à-dire que je viens avec une opinion…

Enfin, j’ai présenté mes opinions dans les épisodes précédents.

Donc ce format-là s’appelle Fissure :

ils viennent avec une thèse et ils essaient de me faire changer d’avis,

de me faire adhérer à leur thèse. Leur thèse est simple :

le métier de développeur peut retrouver de l’intérêt si on remet le client

au centre, si on remet l’interaction entre le dev et le client au centre du métier.

Et c’est comme ça aussi qu’on arrête d’être

juste des devs qui mangent des tickets.

Et moi, autour de cet argumentaire-là, j’ai prévu un octogone de contre-arguments

pour pouvoir voir jusqu’où leur thèse est résistante, jusqu’où eux,

ils arrivent à l’incarner et à la porter. Et vous allez voir si ça s’est bien passé.

OK.

[Question non restituée dans le transcript]

En fait, l’IA arrive à un moment donné où on est passé par plein d’autres étapes.

Il y a eu toute une vague no-code, il y a l’évolution naturelle des produits,

des technos, etc., qui arrivent. Et en fait, tout ça, nous, on n’en a jamais fait

notre principal argument. La techno passe toujours au second plan.

Notre premier sujet, c’était la coopération.

Donc l’IA s’est intégrée naturellement comme un nouvel

outil qui était censé, ou qui est censé d’ailleurs,

qui nous permet d’aller plus loin sur ces enjeux de coopération.

Tant mieux, peut-être, je sais pas. Effectivement, on est passé…

Intéressant.

Oui, c’est ça, exactement.

Oui.

En fait, le no-code a été, à un moment donné, un levier qui nous a permis de dire

: « OK, on peut faire des trucs rapides dans un contexte peut-être plus restreint,

mais qui permet au client d’aller vite, d’aller à l’essentiel,

de vite comprendre quelque chose, de vite se tester.

» Et donc, quand on s’est mis à utiliser Retool ou ce genre de choses,

où le client peut commencer à jouer sur sa base de données,

on apporte le côté : « Tu vas développer un truc, tu sais pas où tu vas,

tu découvres. C’est un outil métier, tu l’as jamais fait. »

On a plein de clients qui avaient toujours des systèmes arriérés.

On a essayé de les emmener vers un peu plus de modernité.

Ça a été une possibilité, en passant par le no-code, de le faire.

Donc l’IA s’inscrit dans cette même démarche, finalement : « Tiens,

là, on a la possibilité de te faire tester un truc rapidement,

d’avoir une démarche très itérative, en pouvant faire beaucoup

plus d’itérations que ce qu’on aurait pu faire par le passé. »

Je suis arrivé il y a à peu près deux ans et assez rapidement,

on m’a dit : « Ici, on fait pas du dev pour faire du dev.

On cherche à répondre à des problématiques clients.

» Si le dev est une solution, ça va en être une. Si utiliser un outil no-code

permet de répondre à la problématique, on utilisera un outil no-code.

Et des fois, on conclura qu’il n’y a pas besoin de produit informatique,

parce que le problème est organisationnel et qu’il faut d’abord changer un geste

métier avant de penser à faire un produit et à développer quelque chose.

Alors…

Si tu veux rentrer sur le côté du

modèle économique, on a un modèle économique particulier chez

Les Fabricants, qui justement nous permet de soutenir plutôt l’expérimentation,

dans une démarche de dire : « C’est quoi, ta dépense acceptable pour tester ?

Qu’est-ce que tu es prêt à perdre, entre guillemets, pour dire :

c’était pas la bonne idée ? » On a des clients qui avaient un budget.

On s’est dit : « Attends, avant de se lancer sur ce budget-là,

on n’irait pas confronter ton idée au réel, faire un petit peu de recherche

sur le terrain, de l’UX, aller faire un peu de strate, pour pouvoir se dire,

au bout d’un cinquième du budget : c’était pas la bonne idée ? »

Et si on avait pris ton budget, on aurait pondu ton truc.

En fait, à la fin, tu aurais un truc qui sert à rien,

puisqu’on vient de le démontrer en prenant un peu de temps au départ là-dessus.

Donc c’est une question de contractualisation

et de modèle économique qui nous permet de faire ça.

Alors, le quantifier, ça va dépendre de ce qu’on cherche à obtenir, effectivement.

Mais le but du jeu, c’est d’essayer de chercher des OKR avec nos

clients au départ, de se dire : « Qu’est-ce qui fait qu’on aura réussi ?

» Il y a des trucs qui peuvent être très simples : je sais pas, Josiane a

retrouvé le sourire, quoi, parce qu’elle n’en peut plus. Et ça, c’est mesurable.

Bon, c’est très subjectif. Donc il faut voir,

il faut trouver les bons leviers,

passer du temps avec le client, comprendre son contexte :

c’est quoi, ses difficultés, et comment nous,

on va pouvoir adapter notre réponse le plus possible ?

Ou de l’étagère. Les clients qui viennent nous voir en disant :

« J’aimerais développer un CRM. » Déjà, des CRM,

il y en a 40 000 sur le marché, et il y en a bien un qui va peut-être

coller à ton truc et coûtera beaucoup moins cher. Par contre, nous,

on a vu que dans le bureau, là, Jean-Michel, il galère avec ce truc-là.

Il y a peut-être quelque chose où tu dois coder le truc un peu plus custom

ou faire un petit no-code, peu importe. Ouais, voilà, exactement. Aussi,

le besoin des clients, derrière, de pouvoir reprendre la main alors

qu’ils n’ont pas forcément de compétences, justement. Des fois,

il y a des outils no-code qui vont être plus accessibles à eux pour aller

mettre à jour leurs datas ou pour aller faire un peu évoluer leur système,

ou les assets dans leur site web, par exemple.

Donc c’est des critères qu’on prend en compte

au moment où on leur propose de choisir

les solutions adaptées pour répondre à leurs besoins.

Les deux. Il y a deux pans de l’activité qui vont être, d’une part, aller chercher

de l’efficacité opérationnelle chez nous au moment de développer des choses, mais

aussi dans toute la phase d’exploration, d’interviews, de discussion,

de réflexion, de capitaliser. Je pense qu’aujourd’hui, l’IA nous aide beaucoup.

Faire un résumé de réunion où tu as été concentré sur la discussion plutôt que sur

prendre des notes, ça peut être un truc intéressant. Quoique prendre des notes,

c’est peut-être aussi pas inintéressant, des fois, pour le cerveau.

Voilà, des équilibres à trouver, en tout cas, là-dessus. Mais pour capitaliser,

pouvoir réinterroger, quand tu as fait un corpus de 20, 21 heures,

se dire : « Je me souviens plus de ce qu’il avait dit, untel », etc.

Ça, c’est des choses hyper intéressantes, sur la partie plutôt analyse amont,

réflexion stratégique. Et après, sur la partie production, oui,

effectivement, en interne, on va utiliser du Codex, du Claude,

le genre de choses qui vont nous permettre d’être plus efficaces.

Tout un tas de skills… Voilà, on a toute une petite équipe

de devs qui a pris le pli, depuis maintenant deux ou trois ans,

de s’autoalimenter, de s’autoformer, puis d’essayer des choses.

Donc oui, ça, c’est d’une part cette partie-là. Et puis après,

l’efficacité opérationnelle de nos clients : qu’est-ce qui permettrait,

pour une tâche à la con de tri d’emails, de tri de dossiers,

d’aller chercher une information dans un corpus, un truc qui t’arrive,

qui est compliqué ? Voilà, on a des sujets aujourd’hui dans l’expertise d’assurance.

Par exemple, quand tu as des gros dossiers qui arrivent et qu’il faut

aller trouver le montant au fin fond du devis du bidule, c’est quand même

une tâche qui est pas très pertinente à faire faire par un humain. Bon, voilà.

Et ça permet à l’opérateur plutôt de se dire : « Je vais passer du temps

avec le client, essayer de comprendre son contexte et redonner de la… »

Voilà. Donc on peut mettre en place de l’agent directement chez les clients,

sur leur métier en général, avec leur expertise, d’ailleurs, avec l’idée de dire

: « Comment est-ce qu’on va intégrer votre expertise dans ce qu’on va produire

pour que ce soit vous qui maîtrisiez ce qui est produit, ce que l’IA produit,

et puis que vous soyez aussi en capacité de jouer sur les potentiomètres ? »

De dire : « Je vais mettre un petit peu plus de ça,

un peu moins de… » Voilà, c’est important aussi.

Ça peut arriver. Ça arrive pas en plein milieu d’une réunion.

Je m’amuse pas forcément à lancer des trucs. Il peut y avoir des tâches

de fond qui sont lancées, mais en général, la réunion, c’est la réunion.

Après, ça pourrait, mais c’est plus mon approche,

qui est un peu plus brute de décoffrage : je vais lui demander des choses,

je vais contrôler un petit peu en direct, regarder ce qui se passe.

Je vais avoir des réflexes, des mécaniques,

tout ce qu’on a mis finalement dans la boîte du steer, comme on a appelé ça.

On va lui demander de documenter en temps réel, de m’informer,

de m’expliquer pourquoi les choses ont été faites, comment elles ont été faites.

De laisser le temps de regarder. Moi, mon approche est comme ça.

Il y en a d’autres. En fait, on travaille pas tous exactement

de la même façon aujourd’hui et on n’a pas vocation à le faire.

Il y en a qui vont demander à leurs agents de leur générer des plans très complets,

et on va voir que l’agent va mouliner pendant une réunion.

Et ça, c’est OK, ça dérange personne. Moi, je travaille un peu différemment,

d’autres vont travailler encore différemment.

Donc on n’a pas de parti pris là-dessus. Juste, on a tous des réflexes,

des habitudes et des choses pour lesquelles on s’aligne à travers le cercle

de développeurs qu’on a. On se dit : « On veut que tous les projets respectent

un cahier des charges. » En tout cas, un pattern où on veut qu’il y ait tout ça

dedans. Après, la manière dont tu le fais… Ça va être des critères de qualité.

En fait, on essaie de faire en sorte que le code produit par quelqu’un puisse

être facilement repris par le collègue qui connaît pas forcément le sujet.

Et avant, on avait des difficultés à ça, justement, parce qu’on a des développeurs

qui sont très impliqués dans le métier, qui le comprennent, qui s’en soucient,

qui ne vont pas développer une feature pour développer une feature,

mais parce qu’ils ont compris en quoi ça va aider le client.

Donc on a des profils un peu hybrides,

où on a des développeurs qui ont à la fois la connaissance métier, fonctionnelle.

Et donc il y avait beaucoup de choses où c’était dans la tête. Aujourd’hui, grâce

à ces outils, on arrive, en parallèle de ce travail-là de pur développement,

où la majeure partie des lignes de code est générée par l’IA… Le développeur

va avoir ce rôle de dire : « On est en mesure de générer la documentation,

de générer les tests à côté, de documenter les pratiques de code sur le projet :

comment j’ai structuré mon code, où j’ai placé mes fichiers,

les interconnexions que j’ai avec d’autres systèmes. »

Et finalement, que le code soit produit par l’IA,

par quelqu’un ou par un développeur avec ses petites mains, à l’ancienne,

j’ai envie de dire, ça sera les mêmes critères qu’il faudra respecter pour

être sûr que ce qui est sorti est d’un niveau de qualité satisfaisant.

Au-delà de la qualité, en fait, on porte une responsabilité,

notamment dans son déploiement chez nos clients. À un moment donné,

on a des clients dans le médical, dans l’industrie, des fois qui bossent

pour le nucléaire. À un moment donné, tu portes une responsabilité.

Avoir fermé les yeux sur ce que l’IA a généré, c’est pas une bonne chose.

Donc on a besoin de garder cette maîtrise-là et cette responsabilité-là.

Le jour où il y aura l’assurance de ton IA, peut-être qu’on n’en sera pas là.

C’est un concept intéressant : assurer les IA, assurer les erreurs que font les IA.

Mais l’idée, c’est plutôt de garder cette responsabilité-là et d’aller au bout de :

« Je te livre un truc, je sais comment il fonctionne et je peux,

moi, être humain, être capable de le dire. »

J’ai été vachement plus vite pour le faire, c’est sûr.

J’y ai pas passé six mois, j’y ai passé trois semaines.

Mais par contre, j’ai une maîtrise ancrée, quand même, de ce que je

produis.

La responsabilité, c’est ça ? Exactement. Tout à fait.

Je pense que c’est des gros sujets. Là, on rentre plutôt dans des sujets d’éthique,

qui sont presque des sujets philosophiques,

mais qui sont hyper intéressants aussi et qui vont de toute façon être amenés à se

poser à un moment donné. Moi, je trouve que c’est intéressant parce que c’est

des arguments qui nous permettent d’aller face à nos clients en disant : « Attends,

tu veux que je… Je peux te faire un truc, ça va te coûter rien du tout.

Je vais tout demander à l’IA de le faire. Par contre,

tu prends la responsabilité de ce qui est produit,

et s’il y a un problème… » Et dans les faits,

c’est vachement intéressant d’avoir cette discussion-là :

« Non, je veux qu’il y ait un humain qui regarde,

je veux pouvoir vous faire confiance.

Vous produisez un truc et je vais pouvoir me retourner

contre vous aussi. » Enfin voilà, c’est un vrai sujet.

Tout à fait.

C’est ça qui est intéressant :

« On va commencer avec un petit budget et on va pouvoir tester des trucs.

Il y aura peut-être des failles dedans, mais on est dans un mécanisme de test.

OK, tu es d’accord avec ça ? » « Non, je suis pas d’accord.

Je voudrais au contraire un peu plus de sécurité dès le départ,

parce que ça m’inquiète, ces trucs-là. Je veux pas…

» En fait, on a ces discussions-là qui sont intéressantes,

et donc à partir de là, on calibre. Finalement…

Et ces critères de qualité, ils sont pas là que pour nous,

on les partage aussi à nos clients. C’est-à-dire qu’on sait qu’à des moments,

peut-être pour un besoin business un peu urgent,

on va devoir passer un petit peu au-dessus pour pouvoir délivrer quelque

chose rapidement et répondre à un enjeu que le client a. Eh bien, on lui dit.

« Là, on a été un peu vite, on a dû un peu forcer le passage pour te

mettre ta fonctionnalité dont tu avais besoin. C’est un petit peu dégradé,

on n’a pas été, d’un point de vue qualitatif, forcément au rendez-vous.

Il faudra qu’à la suite, on accorde un temps pour rattraper ça,

l’absorber, et faire en sorte que, pour la suite, on soit… »

[Début de phrase non restitué] Et là, il en a conscience. Il est pas stupéfait

plus tard de dire : « Ah, mais comment ça se fait que j’ai ce problème ?

Ça, ça n’a pas été mis à jour », etc. Tu l’as su tout de suite, en fait.

On a été vite pour toi, mais on t’a mis aussi au courant que ça avait

un petit peu dégradé, et donc il faudra qu’on le rattrape par la suite.

Alors aujourd’hui, on a limité aux abonnements de base.

Quasiment tout le monde a du Claude ici et c’est limité à l’abonnement.

C’est-à-dire qu’on ne va pas chercher du token supplémentaire. Si t’as cramé tes

tokens, tu utilises ton cerveau ou tu vas faire autre chose. Et ça veut dire aussi

qu’on a une réflexion sur l’optimisation de l’utilisation de ce truc-là.

Si tes sessions de cinq heures de Claude, en une heure,

elles sont cramées, c’est peut-être que tu utilises pas très bien le truc…

Et après, sur la partie plus

consommation,

ad hoc, si on développe un truc pour un client,

il prend son abonnement et puis on utilise le sien, c’est à lui.

Si lui crame beaucoup de tokens parce qu’il a beaucoup de dossiers à traiter,

voilà, c’est sa facturation. Et par contre, nous, on va plutôt être

sûrs qu’on fait du code optimisé, qui va appeler correctement les IA.

On travaille pas mal avec Mistral, en général, sur les sociétés

françaises qui ont besoin d’un peu de souveraineté, qui s’inquiètent

un peu de l’endroit où elles ont leurs datas. On va essayer de monitorer

la consommation qu’on fait, de voir si un appel est pas dément,

quel contexte on a passé, etc.

D’avoir une vraie démarche d’utilisation pertinente et maîtrisée.

Et c’est aussi un aspect qu’on met dans le steer.

Il y a la maîtrise de ce qui est produit, la maîtrise de la compétence aussi :

je produis quelque chose dans lequel je monte en compétence,

si je n’étais pas à l’aise au début. Mais aussi la maîtrise, même si

aujourd’hui on utilise des abonnements, sur la manière dont on l’utilise.

Ça va être la mise en place de fichiers mémoire pour orienter l’IA

dans mon projet. Ça va être l’utilisation du bon modèle au bon endroit,

pour ne pas utiliser les trop gros modèles pour des petites tâches simplistes.

Ça va être tous ces petits réflexes-là. L’utilisation de plusieurs sessions pour

bien découper, pour pas faire grossir des contextes de manière exponentielle à côté.

Donc voilà, ça fait aussi partie de ce qu’on met derrière,

de maîtriser cet aspect-là de ce comportement. Parce que si demain

les prix explosent, est-ce qu’il faudra absolument qu’on suive ?

Si on a les bons réflexes, on pourra peut-

être modérer.

C’est plus des réflexes, parce qu’on est dans un modèle où on travaille…

On pourrait faire une formation.

Ouais, on l’a…

Pas, on l’a pas posée pour l’instant, parce qu’on le travaille

quotidiennement en équipe. En fait, on a le cercle des développeurs,

et une fois par semaine, on échange sur tous ces sujets.

On a des sessions où on est tous ensemble sur un aspect particulier.

Donc au fur et à mesure, tout le monde est formé un peu à tous les aspects.

Après, c’est pas une pratique, c’est plus des réflexes à avoir,

parce qu’on a différents types de projets : des projets où on va

commencer from scratch, des projets legacy qu’on va reprendre.

On pourra pas mettre les mêmes choses au même niveau à chaque

fois. Donc c’est juste : je reprends un projet, je vais avoir ces réflexes

de documenter ce que je vais faire, de toucher seulement une petite partie,

de rajouter des tests de non-régression dedans.

Mais c’est seulement sur cette partie sur laquelle je vais intervenir,

par rapport à un projet où je vais tout faire proprement dès le début.

C’est juste des habitudes à avoir.

Au moment où je développe avec mon IA, je maîtrise ce que je…

Ouais, une partie, effectivement.

Oui, tout à fait, c’était l’objectif.

Et donc on a repris six codeurs, en fait.

Alors non, effectivement, ils ont pas, je pense,

autant poncé les sujets de l’IA à l’époque où ils étaient chez IKOMOBI.

Et donc on va amorcer une démarche. Ils sont là depuis deux mois à peine…

Donc là, on est en train de regarder comment on va les intégrer à ce cercle,

leur faire part de nos pratiques.

En fait, ils vont rentrer dans la démarche, ça va aller tout seul.

Ce cercle-là intègre des développeurs tout le temps, régulièrement,

à chaque fois qu’il y a des nouvelles compétences. Non, ça, c’est sûr,

effectivement. Quoique, il y a deux ans, on a fusionné avec Inouit.

Voilà, on a récupéré une dizaine de personnes d’un coup.

Bon voilà, ce sont des choses qui se travaillent,

en réfléchissant à quelles vont être toutes les petites étapes,

qu’est-ce qu’on doit faire. Nous, on a des petits process

plutôt RH qui permettent de gérer un peu ces périodes-là.

One-to-one… Ça dépend des dispos de l’équipe.

Après…

C’est bien tombé aussi qu’ils sont arrivés au moment où, justement,

on travaillait cette conférence. Donc ils sont arrivés et ils y ont assisté,

comme ça ils se sont tout de suite imprégnés.

Et après, au quotidien, on travaille avec eux pour se l’approprier,

pour qu’ils puissent le mettre en place aussi.

Je pense que le contexte client est hyper important.

C’est aussi ça qui permet d’avoir cette capacité à rentrer là-dedans.

Et sur le côté RH, moi, je vois un truc qui se dessine, qui est assez intéressant.

Il y a une grosse peur, je pense légitime, notamment de dire :

« Les juniors servent plus à rien parce que l’IA fait tout plus rapidement. »

Un senior, il sait ce qu’il faut faire. Avant, il le donnait à un junior.

Il prenait le temps qu’il fallait, puis il apprenait grâce à ça,

et puis il se seniorisait tout doucement grâce à ça. Je pense qu’il y a quelque

chose de vrai là-dedans. C’est sûr qu’aujourd’hui, si on fait pas gaffe,

on n’a plus que des seniors. Et voilà : les seniors de demain, qui seront-ils ?

Mais en fait, ce que je vois, et notamment ça déplace un petit peu le sujet

de « qu’est-ce que je fais en tant que junior ? », c’est cette capacité,

cette plasticité, j’ai envie de dire, de s’adapter à un côté :

« Je vais commencer ma carrière avec une IA. » Et donc, moi,

je trouve ça très intéressant : ayant travaillé cette mécanique,

plutôt méthodologique, d’utilisation de l’IA au quotidien, c’est comme ça

qu’on va faire rentrer, je pense, des juniors là-dedans. Et finalement,

ils n’apprendront plus au contact d’un senior qui t’a donné une tâche à faire,

puis qui est venu la reviewer ; ils apprendront au contact d’une IA

qui aura fait un truc. S’ils sont assez malins pour dire :

« J’ai envie de comprendre », il y aura cette démarche-là.

On a des développeurs qui se font des formations ou des tutos grâce à l’IA :

« Écoute, là, je vais prendre une nouvelle techno.

» On l’a fait récemment avec JS, un truc de 3D, pour un client.

« Fais-moi un tuto pour que j’apprenne à me servir de la librairie,

que je comprenne tout ce que tu vas faire, toi, parce que sinon je ne

vais pas être en maîtrise de ce que… » C’est un junior qui est chez nous,

qui est câblé, qui a cette plasticité-là, de dire : « OK, je vais

apprendre, je vais bouger. » Et puis il prend le truc, d’ailleurs,

qui nous apprend aussi, à nous, de se dire : « Comment cette nouvelle

génération va devoir appréhender les choses et vivre avec ça ? »

La grande question, c’est pas de savoir : « Est-ce que je suis junior ?

» C’est : « Pourquoi ça m’intéresse et pourquoi je faisais ce métier ?

» Si c’était pour faire des lignes de code, effectivement, là,

c’est compliqué, parce que les lignes de code, on ne va plus les faire…

On les fait vraiment par petites touches, par plaisir. Mais par contre,

si j’étais là pour résoudre des problèmes grâce à des solutions, des outils

informatiques, juste les outils ont bougé, mais l’objectif est toujours le même.

Donc après, avoir de la curiosité, chercher les bonnes technologies

pour répondre aux bons problèmes, comprendre comment elles fonctionnent

et maîtriser tout ce qui se passe dans mon système… À partir du moment

où j’ai cet état d’esprit-là, peu importe comment j’y arrive, en fait,

j’ai toujours les moyens de le faire. Avant, il fallait que je code. Maintenant,

il va plus falloir que j’explique bien à mon agent quelle est mon architecture,

comment il doit faire, ce qu’il doit respecter.

Mais l’objectif, le résultat et l’intention restent les mêmes.

Et donc les développeurs, là, s’y retrouvent.

Il y a quelques années…

[Suite non restituée]

Je pense que c’est quelque chose qu’on faisait déjà avant. En fait, tu vois,

c’est ce que je disais : on cherche des gens qui ont envie de se mettre

au service d’un projet, d’un client, de quelque chose. On a toujours eu déjà

cette démarche d’aller chercher chez les gens, pas leurs super skills techniques,

le mec qui connaît le C++ sur le bout des doigts,

mais plutôt celui qui est un peu MacGyver, touche-à-tout,

qui a cette capacité de comprendre, qui va mettre en œuvre des choses.

Et puis il y en a qui sont arrivés avec des compétences de code moyennes,

qui les ont apprises ici, parce que justement, on les a amenés…

Il y en a qui sont arrivés avec des super compétences de dev

et qui ont permis de faire, mais toujours avec ce lien, en disant :

« On va essayer d’équilibrer une équipe capable de se poser les bonnes questions.

» On n’a personne qui prend un ticket ici, dans son coin,

recrache le truc sans se poser de « pourquoi ». Je voulais juste dire un truc…

Ouais.

Quand tu parles de ça, on faisait régulièrement des conférences. On n’en

fait plus trop, mais on en a refait une récemment avec ce truc du steer.

J’avais un développeur, petit clin d’œil à Gaëtan s’il nous entend,

qui avait fait une petite conf, un petit moment où il disait :

« Le métier de développeur, c’est le plus beau métier du monde parce qu’à

travers le métier de développeur, je peux voir tous les métiers des autres. »

Et en fait, je pense que c’est vraiment le truc qui fait la différence.

Quand tu as cette approche-là : « Moi, ce qui m’intéresse,

c’est de découvrir des choses, apporter des solutions »,

le développement est un moyen. Je suis le premier exemple :

je ne suis pas développeur de base. J’ai toujours codé dans mon coin,

j’ai appris en autodidacte, j’ai monté la boîte là-dessus,

une boîte de dev, alors que j’ai jamais suivi d’études de dev.

Donc ça pourrait paraître contre-intuitif, mais ma volonté à moi,

c’est de résoudre le problème de quelqu’un. C’est comme ça que j’ai

monté mes premiers projets. Les plus vieux clients qui sont ici,

c’était : « Tu veux pas me filer un coup de main ?

J’ai un problème dans mon entreprise. » Je me suis dit : « Développer,

c’est un bon moyen de faire des trucs et de produire quelque chose pour toi. »

Donc on continue cette tradition. On peut appeler ça comme ça.

Mais en tout cas, par rapport à la question d’origine, moi,

ce que j’aime bien faire en entretien, c’est poser un sujet.

Je ne vais pas faire un test technique, ce genre de choses. Par contre,

je vais poser une problématique qu’on peut rencontrer, assez vague,

et je vais regarder : ça va être quoi, les premiers réflexes du développeur ?

S’il me dit : « Je vais mettre en place une stack,

je vais mettre en place un front-end, puis je vais les faire communiquer comme ci,

comme ça », ça va être différent de s’il creuse un peu le problème, dit :

« Il y a peut-être deux ou trois aspects que j’ai pas compris. Pourquoi est-ce

qu’on veut faire ça ? » Et ça, ça me donnera une idée de son état d’esprit.

Parce qu’après, les solutions techniques, même avant l’IA,

on savait que la bonne techno, les manières de faire,

on avait déjà des ressources en ligne, on y arrive toujours.

Le test technique brut, de but en blanc : « Comment tu écris ta classe ?

», c’est pas très intéressant. On arrivera à le faire quoi qu’il arrive.

En tout cas, on cherche pas cette expertise-là. Donc c’est vraiment comment

il va aborder un sujet assez vague que je lui donnerai : est-ce que c’est

plus par l’aspect métier, fonctionnel ? C’est quoi, son objectif dessus ?

Si c’est directement dans la technique,

ça va donner un petit peu une tendance sur le profil.

C’est une fois par semaine, donc il faut de la régularité.

Une heure, parfois deux, quand on estime que le sujet en vaut la peine.

On a changé le rythme récemment : on est passé à tous les quinze jours,

une session de deux heures. Je dis ça parce que ça bouge.

Il y a six mois, c’était pas ce rythme-là, etc. Ça dépend, exactement.

Et on s’est rendu compte qu’il y a un côté aussi, de temps en temps,

à changer un petit peu l’organisation pour remettre un petit peu d’énergie dedans.

Donc là, on se donne un peu plus de temps, on prévoit à l’avance des sujets

qui tiennent sur la première heure, un sujet précis. Ça peut être un projet,

une nouvelle techno, un usage de l’IA que j’ai découvert et sur

lequel je me perfectionne, et que je vais partager avec les collègues.

Donc une heure consacrée à ça, et ensuite, le reste du temps,

c’est un tour de table pour savoir si quelqu’un a besoin d’aide.

Et puis ça peut aussi reprogrammer les sessions d’après.

Voilà, il y a un rythme et toujours quelque chose de prévu.

Alors depuis qu’on a IKOMOBI, on a récupéré justement des sujets

et des contrats avec un petit peu de régie. Mais c’était jamais le cas avant.

On n’a jamais eu ce genre de pratique. C’est nouveau, et tant mieux.

On va découvrir cette pratique-là, et ça ne va pas nous empêcher de venir y

mettre notre sauce et de dire : « En fait, une régie pertinente, c’est quoi ? »

C’est une régie avec les bonnes ressources au bon moment. Donc on avait des façons

d’approcher les enjeux de régie plutôt en mode équipe qu’en mode personne.

On va pouvoir aussi continuer à travailler ces mécaniques-là avec du concret,

avec des clients qui ont des ressources chez eux. Et donc,

du coup, intégrer évidemment ces équipiers-là dans ces cercles-là.

Et le cercle, il a surtout une vocation apprenante.

Avec aussi quelqu’un qui va mener, entre guillemets, l’organisation.

Il y a un président, plus ou moins on l’appelle, en tout cas quelqu’un qui a…

On a…

Un maître de cérémonie, voilà.

Un représentant et un…

C’est ça. Donc voilà, qui s’assure aussi que…

Le représentant, lui, il a vocation à potentiellement

représenter le cercle auprès d’autres cercles dans la boîte.

On est organisés un peu comme ça, en cercles de fonctionnement :

un cercle orga, un cercle sur la partie plutôt design, un cercle RH.

Et donc il peut y avoir des sujets où on va inviter un membre représentant

d’un des cercles dans un autre cercle, puisqu’on a besoin de son expertise.

J’en sais rien : s’il y a une décision stratégique et financière au cercle

des devs, en disant : « Là, on voudrait passer sur tel truc, tel abonnement,

ça va demander… », on va faire appel à quelqu’un du cercle finance,

qui va pouvoir dire : « OK, dans nos projections, ça peut fonctionner.

» Voilà, on essaie d’avoir ces démarches-là. Et le président,

lui, est là pour s’assurer que le cercle est tenu, qu’

il y ait bien des sujets, un ordre du jour,

et éventuellement qu’il aille titiller la personne :

« N’oublie pas, dans deux jours, c’est toi qui présentes un truc.

» Enfin voilà, c’est plus une question d’animation, et c’est tournant.

Ouais, c’est un peu inspiré de ce genre d’inspirations, en fait.

On aime bien aller chercher un peu partout dans les méthodos

qui existent des trucs qu’on s’approprie et qu’on fait à notre sauce.

Donc on respecte pas forcément stricto sensu

ce qui peut être écrit dans la méthode [nom incertain].

Peut-être ? [Question incomplètement transcrite]

Non, j’ai pas du tout cette impression-là. Moi, je trouve qu’on a

gardé une mécanique vraiment récurrente de se voir avec nos clients.

On a une mécanique un peu à trois étages, plutôt de weekly.

Alors des daily, c’est assez rare, ou alors vraiment sur des très gros

projets où il y a besoin d’animer. Mais c’est par sujet ou par équipe.

On a plutôt des weekly qui nous permettent de voir ce qui va se passer la semaine

d’après. En plus, comme nous, on a un staffing qui s’adapte en fonction

de la demande, c’est aussi important de voir ça. Des monthly, qui sont plutôt

une revue un peu globale, un point tactique, on va dire, d’organisation.

Et puis après, on va avoir des choses tous les trois, quatre, cinq, six mois,

ça va dépendre des clients, qui sont plutôt stratégiques :

est-ce que nos enjeux stratégiques, ce qu’on est en train de développer,

de faire, de mettre en place, les pratiques qu’on est en train de faire

évoluer chez toi, est-ce qu’elles sont toujours alignées avec ta stratégie,

toi, client ? Ces étages-là, ils sont importants.

[Question non restituée dans le transcript]

[Suite de la question non restituée]

Alors, tu ne vas pas les lire parce qu’il va t’en générer beaucoup d’un coup.

Mais justement, ça fait partie des petites pratiques dans le steer :

on fait petit, on fait rapide, on fait efficace. Lire trois lignes

de documentation d’une petite fonctionnalité dans un coin du code,

je vais le faire plus facilement, parce que j’aurai bien découpé mon développement

et j’aurai bien fait minimaliste à chaque fois, pour qu’à la fin,

j’aie eu le temps de tout relire et de m’assurer que c’était conforme.

Après, comment on y arrive ? En faisant l’exercice, en fait.

Comme j’en parlais, on a des sujets de staffing où, de temps en temps,

le client va demander quelque chose, mais on n’a pas forcément la ressource

au bon moment, la personne qui avait travaillé à l’origine sur le projet.

On va avoir besoin de faire monter quelqu’un d’autre. Eh bien,

elle va faire l’exercice, et s’il y a des zones de flou, il va les lever.

Et puis au fur et à mesure…

La documentation, elle est aussi vachement liée à l’agent du voisin qui va la lire.

C’est aussi important de se dire : ce que je capitalise là dans le projet,

que j’avais peut-être pas fait par le passé, va aussi permettre de faire

en sorte que l’IA qui reprend le projet ait un peu l’historique,

le parcours par lequel on est passé, les informations, le cheminement de ce projet.

Les choses qui aujourd’hui se passaient plutôt à l’oral : six mois de projet,

puis tu passes la main à quelqu’un. Tu vas lui faire une passation,

ce genre de choses, tu vas lui raconter : « Ça, ça vient de tel truc. »

Et cette mémoire-là, en général, tend à se perdre.

Là, je pense qu’on a une opportunité de faire en sorte que cette mémoire reste.

On n’a pas une structure fixe.

On ne va pas forcément aller mettre beaucoup

de commentaires dans le code pour dire ce qu’il fait.

On va plutôt avoir des réflexes de dire : « On découpe bien notre projet,

on a des sources qui sont mises à des endroits particuliers.

» À côté, on va avoir le petit Markdown qui va bien,

qui explique pourquoi ça a été fait, comment ça a été fait.

C’est pour ça qu’aujourd’hui, tu parlais de review : limite,

on n’y est pas encore totalement, mais on va tendre de plus en plus à se

dire que la review la plus importante, ça va être la documentation à côté,

qui reflète ce qui est développé et qui nous permet de voir si ça correspond bien

à ce qui a été demandé. Derrière, si c’est fait en 3 000 lignes de code ou en dix,

finalement, si ça fait bien ce qui a été demandé…

D’un côté, si la documentation reflète bien le code.

On l’a pas fait sauter.

On la fait juste un peu différemment. Aujourd’hui, on est beaucoup sur Claude,

qui donne des fonctionnalités de review, et on va s’en servir.

On a même des skills, on commence à faire des skills autour de ça :

comment je review une PR ? C’était déjà un sujet avant, en fait.

Comment je review une PR ? Est-ce que je parcours juste les lignes de code,

puis je regarde quand il manque un point-virgule, etc. ?

Ou est-ce que je lance l’application ? Je la teste d’abord et après,

je regarde le code ? Ou est-ce que je vais voir le ticket ? C’était déjà pas

évident pour tout le monde de savoir comment on pouvait bien reviewer du code.

Donc aujourd’hui, on continue de le faire sur les équipes, en tout cas

où on arrive à plusieurs développeurs, ce qui n’est pas toujours le cas.

Et quand on le fait, on se sert de l’IA pour dire : « Il y a beaucoup

de code dans cette PR. » Des fois, je sors une PR où il y a beaucoup de code.

« Aide-moi à pointer ces aspects-là qui m’intéressent,

les aspects structurants, les aspects où il y a un algorithme un peu complexe.

Explique-moi l’algorithme, comment il est implémenté,

pourquoi il a été implémenté comme ça. » Et par contre,

je ne vais pas me taper tous les imports qui sont en début de fichier,

ou ce genre de choses. Je vais me concentrer sur la partie importante,

et la plupart du temps, c’est pas la majeure partie du code.

Pas sur chaque, je pense pas. Mais ce qui est important dans notre mode

d’organisation, c’est aussi de dérisquer les ressources pour nos clients.

On a très rarement des projets où il y a un seul mec qui est capable

de mettre les doigts dedans. On essaie toujours d’avoir un pair.

Alors, on a un cercle delivery, c’est pas le cercle dev :

c’est plutôt un cercle qui est vigilant sur ces enjeux de qualité, etc.

Et donc là, on va aller chercher effectivement des seniors,

mais qui ont cette capacité de dire : « Moi,

je vais venir sur ton projet pour le titiller. Je le connais un peu,

je veux le comprendre, je vais peut-être faire des reviews de PR.

» Et donc on essaie aussi d’avoir une mécanique organisationnelle

pour maintenir, quoi qu’il arrive, une connaissance projet,

une connaissance client un peu plus large que sur une personne.

Pour moi, le sujet est pas là. Le senior, lui, va au-delà de la partie code.

Il va s’assurer de la cohérence projet, de ce que ça va délivrer,

de ce que ça va produire chez le client. Regarder du code juste pour

le code et savoir si son exécution est bonne, ça n’a aucun sens.

OK, ça s’exécute, ça fait un truc. Si ce truc n’a aucun impact chez ton client,

quel intérêt ? Donc c’est pour ça qu’il faut vraiment envisager de déplacer…

Nous, on le fait depuis très longtemps,

mais je pense que c’est important pour toutes les boîtes qui ont juste

pondu du code jusque maintenant sans se poser la question de la finalité :

déplacer cette capacité de review et de compréhension sur ce qui est livré, est-ce

que c’est en adéquation avec un besoin métier, terrain, une réalité concrète ?

Et aujourd’hui, ce qui est vraiment bien aussi, je pense que l’IA peut aider,

c’est qu’on va pouvoir itérer beaucoup plus rapidement là-dessus.

Et donc le senior, pour moi,

a cette responsabilité-là dans ce que je décrivais : d’avoir ce pas de côté,

ou ce pas en arrière, cette vue d’ensemble. Il a cette responsabilité-là.

Dire : « Je veux pas juste venir commenter ton code pour dire :

tu pourrais utiliser un point plutôt qu’un…

» J’en sais rien, enfin, aucun intérêt.

Donc c’est vraiment l’idée de dire :

le senior vient apporter ce regard, du lien avec le terrain.

Parce que moi… [Suite de la question non restituée]

Alors nous, on essaie d’en faire le moins possible parce qu’on trouve qu’en général,

c’est là où la valeur est la plus intéressante. Donc on essaie de dire

à nos clients qu’on va plutôt avoir une démarche de découverte.

Est-ce qu’il n’y a pas une dépense acceptable pour découvrir ?

Et de toute façon, in fine, il va ressortir avec de la matière

qui va lui permettre de dire : « OK, mon projet est bon,

je vais le faire comme ça », ou : « C’est ça qu’il faut faire ? »

Enfin voilà, on essaie vraiment de déplacer ça. Et ça, ça fait longtemps

qu’on le fait : on va pas passer six mois en avant-vente pour un projet.

On va essayer de faire en sorte de valoriser cette partie-là,

qui, à notre sens, est l’une des valeurs les plus importantes du projet.

Bien démarrer, c’est plus intéressant.

Donc je pense que ça a quand même pu diminuer un peu le ticket d’entrée,

notamment parce qu’on peut tester des trucs. Ce qu’on voit arriver,

et qui, à mon avis, va décupler, c’est le client qui vient avec déjà quelque chose.

Il a pris son abonnement Claude Code,

et puis il a sorti tout un truc où ça marche, ça marche déjà.

Alors derrière, quand on ouvre le capot, c’est compliqué.

Comment il raccroche ça à son SI ? La sécu, elle a été gérée comment ?

Les autres certifications, j’en sais rien… La gestion de tout ça, des droits,

du stockage. Il y a tout un tas de questions que lui s’est pas posées.

Nous, on a encore un peu de valeur ajoutée là-dessus.

Peut-être qu’on en aura de moins en moins.

Parce que les skills, justement, seront de plus en plus forts,

et ça produira des choses de plus en plus…

Avec le no-code ? Oui, je pense clairement, parce qu’en fait, finalement,

on refait quand même beaucoup plus de custom. In fine, qu’il ait été produit

par une IA ou un humain, peu importe. On va pouvoir refaire plus de custom.

On n’utilise quasiment plus… Je prends un exemple : Retool, qui nous

permettait de faire des interfaces connectées à des API, des machins.

C’était hyper intéressant pour prototyper un truc.

Le client pouvait déplacer un bouton s’il voulait, s’il avait un peu d’appétence.

On pouvait faire des trucs intéressants comme ça.

Aujourd’hui, je me pose pas de questions. Si j’ai des API,

tu donnes ça à Claude, il te fait une interface en deux-deux.

Et si le client veut déplacer son bouton, il va le faire aussi simplement.

Donc ça s’est juste déplacé.

Ça a remplacé un certain nombre de ces outils no-code-là.

Tu vois, il a… [Suite de la question non restituée]

On a des clients qui sont comme ça. Des clients qui, par contre, viennent nous

chercher pour pouvoir mettre en place avec eux un environnement qui leur permette

de faire ça. De dire : « En fait, je veux pas que le gars dans l’atelier,

lui, la couleur lui plaît pas, il puisse demander de changer le truc,

et puis en fait, il vient d’introduire un problème.

» [Terme incertain] Parce que lui, il avait pas de vue d’ensemble du projet.

Donc on essaie de faire en sorte de mettre les garde-fous,

de réfléchir à ces plateformes. Mais je pense que ça va venir aussi,

des plateformes qui te permettent de développer et de continuer

de développer dans un contexte un peu sécuritaire.

C’est d’avoir des… [Suite non restituée]

Ce qui est intéressant, c’est que c’est aussi une autre manière

d’exprimer un besoin. On a certains clients qui disent :

« On ne va pas faire 36 000 réunions, on ne va pas faire plein de trucs.

Je vais coder dans l’application quelque chose, et puis après, voilà, je l’ai fait.

C’est comme ça que je l’imaginais, c’est ça que ça doit faire.

Est-ce que vous pouvez me le faire proprement, ou en tout cas,

on en discute ? » Mais j’ai plus facilement posé mes idées en le faisant

comme ça qu’en essayant d’expliquer dans une réunion, etc. C’est hyper pratique.

Oui, voilà.

Alors…

Globalement, on a quand même assez peu de clients comme ça,

mais on en voit qui arrivent. Et c’est de nouveaux clients, en fait,

c’est un nouveau public. Moi, je pense que ça a apporté la capacité à un certain

nombre d’entrepreneurs de pondre des choses qu’ils n’avaient jamais…

Une petite boîte qui a un petit chiffre d’affaires et qui se serait jamais

payé une appli à 200 000 balles, aujourd’hui, elle peut se l’imaginer.

Et le gars, le dirigeant, va passer ses nuits sur Claude. Il va kiffer

parce qu’en plus, il est capable de sortir ce qui, depuis des années,

l’emmerde dans sa boîte. Il sait exactement comment elle fonctionne,

sa boîte, et il peut produire quelque chose. Ça, ça va arriver.

Il y a une grosse vague de gens comme ça. Et puis derrière, ils viennent te voir

parce qu’aller le déployer et le mettre en prod, ça les fait un peu flipper.

Ou ils se rendent compte qu’ils maîtrisent pas tout,

ou que ça marche pas. Juste, ils n’arrivent pas à le faire, quoi.

Ils n’arrivent pas à faire en sorte que ça marche, il y a toujours un bug.

Donc là, je pense qu’il va y avoir toute une vague de support,

entre guillemets, des gens qui auront développé avec l’IA.

Garder cette compétence d’être capable de le faire, c’est intéressant.

Oui.

C’est ça.

Voilà, c’est ça.

C’est une discussion. Tu as des discussions avec le client, tu dis : « OK,

on n’assume pas le code qui a été fait, mais il tourne et te rend service.

Il y a peut-être quelques failles. Si on voulait les combler,

il faudrait plutôt passer par là, mais ça va te coûter trop cher.

» « Laisse tomber. » Le client fait son choix.

Je veux dire, à un moment donné, le client utilise une scie circulaire

où il n’a pas la sécurité qui empêche que le doigt se coupe.

Il a fait son choix de dire : « J’ai pas les moyens de me payer cet équipement-là,

je vais faire plus attention, je vais pas me faire couper.

» Bon, on va avancer dans la même chose. Il va mettre en ligne un outil avec…

Il faut l’aider à mesurer son niveau de risque,

son niveau d’exposition de ses données, etc.

Dire : « Attention, si tu mets ça en prod, tes datas sont en clair,

j’en sais rien, des tokens… Tu vas te faire pomper ta base clients.

» Donc à nous d’apporter cette expertise-là, et ensuite à lui de choisir.

« Bon, OK, j’ai pas les moyens de me payer ça, ça restera à l’état de projet.

» Ou alors : « Non, au contraire, il faut que j’investisse. » C’est intéressant,

il y a une nouvelle génération de clients qui arrive, je pense, grâce à ça.

Le travail de génération de documentation va être intéressant aussi,

parce qu’il va générer une application. On va travailler avec le client pour dire :

« Explique-moi pourquoi tu as fait ça. » On va générer un peu la documentation,

tout ce qui explique tous les mécanismes que tu as voulu mettre dedans,

qui ont été faits d’une certaine manière. Une fois qu’on l’aura,

on pourra la prendre, puis refaire quelque chose proprement, à moindre coût,

parce qu’on aura toute la matière utile comme source de vérité.

Voilà, c’est…

Ça.

Les évolutions…

Le mot de la fin.

Notre mot de la fin…

Enfin, je pense : n’ayons pas peur de cette vague-là.

Regardons-la avec du recul et en n’ayant pas peur de tester.

Essayons des choses, trompons-nous, faisons des erreurs.

On apprend de ses erreurs comme on l’a toujours fait,

en tout cas chez nous, chez Les Fabricants.

On a toujours eu cette démarche-là d’être curieux et d’essayer.

Et puis advienne que pourra. On l’a toujours dit chez Les Fabricants :

si un jour on fait plus de code parce qu’en fait il n’y a pas besoin, eh bien,

on fera autre chose. Si un jour il faut prendre un marteau et un tournevis,

et que c’est ça qui fait qu’on rend service au client et qu’on

apporte la bonne réponse à sa problématique projet, on évoluera.

Alors peut-être qu’il y a des collaborateurs qui diront :

« Non, je voulais faire que du code. » En tout cas, l’idée,

c’est vraiment cette approche qu’on a ici : on veut rendre service,

faire en sorte que ça marche. Quelque chose qui soit utile dans ton entreprise,

qui ait des impacts les plus bénéfiques possibles, sociaux, économiques.

Donc je pense que l’IA a probablement des avantages, quelques inconvénients aussi.

Regardons-les, regardons-les de loin et voyons comment ça se passe.

Et restons curieux.

Tant qu’on l’est, ça sera sur d’autres technologies, sur d’autres manières

de pratiquer, mais on aura toujours quelque chose à faire d’utile.

Ce sera juste d’une autre manière. L’IA n’est pas un ennemi, c’est juste un outil

supplémentaire qui fait évoluer notre métier plus rapidement que d’autres.

Mais finalement, on a toujours été dans un métier qui évoluait.

OK, c’est cool.

Merci à toi.

Bon, alors j’espère que vous avez passé un bon moment.

Je me remets dans le costume d’arbitre. Un jour, peut-être,

je vais acheter un déguisement d’arbitre. Je me remets dans le costume d’arbitre.

Alors, est-ce que Ben et Alexis m’ont fait changer d’avis ?

Pas vraiment. Mais en vrai, ce serait bête de leur reprocher ça.

C’est-à-dire qu’en arrivant chez eux, j’avais déjà commencé à changer d’avis.

En fait, ils ont rebondi sur l’épisode qui s’appelle « Ce métier est devenu

chiant ». Et vous, si vous avez écouté l’épisode qui est sorti juste avant l’été,

qui s’appelle « Personne ne monte dans un avion qui est piloté par Claude »…

En fait, j’ai déjà commencé à changer d’avis sur cette thèse-là, je pense.

Je pense très honnêtement que tous les développeurs et toutes les développeuses,

en ce moment, traversent les phases du deuil, tout simplement.

Et ça, ça se voit à plein de niveaux.

En particulier, si vous regardez mon podcast, moi, j’ai l’impression

de voir les phases du deuil. À un moment : « Ce métier est devenu chiant »,

et à un moment, une phase d’acceptation. Il y a des phases de négociation.

Et je vois aujourd’hui, dans les réactions des développeurs ou

des développeuses autour de moi, qu’on passe par ces phases-là.

Donc probablement que la saison précédente du podcast, pour moi,

c’est les phases du deuil par lesquelles on passe tous et toutes.

Et je suis dans la phase d’acceptation, et je pense que Ben et Alexis

sont déjà sur la phase d’après. Ils ont déjà accepté depuis longtemps.

Et ce qu’ils montrent, je trouve ça assez excitant :

un monde où le client va prendre son IA pour avoir un rendu qui est proche

de ce qu’il veut faire, en tout cas, et demander aux développeurs de le… de finir.

Mais moi, ça me va.

Si je suis graphiste, par exemple,

et que le client a fait un logo avec ChatGPT pour m’expliquer ce qu’il veut,

et que son intention est beaucoup plus claire que s’il m’avait fait un brief

flou, eh bien, en fait, oui. Alors, OK, c’est de la reprise technique, etc.

Mais il y a de la place, quand même, pour avoir une conversation en face.

Est-ce que tu préfères… Moi, je préfère encore que le client ait fait

un prototype, fonctionnel ou pas, qu’un ticket Jira obscur et que j’aie besoin

d’essayer de comprendre ce qu’il veut, ou de le rappeler pour comprendre.

Il ne faut pas y voir le client ou le non-tech

qui essaie de mimiquer notre travail.

Il faut plutôt y voir le non-tech ou le client qui essaie

de dépasser les barrières techniques qu’il y a entre nous

pour commencer à avoir une collaboration qui va plus loin.

Ce qui a bougé chez moi… Si vous vous rappelez dans l’histoire,

enfin dans mon histoire à moi, il y a des moments où

je code beaucoup et je suis à mon bureau tous les jours au centre

de services chez Altran. Et puis ensuite, je vais en agence

et je vois les clients une fois par semaine en démo.

En fait, dans mon parcours, plus je passe de temps avec les clients…

Moi, je suis dev, et même sur WeLoveDevs avant… Quand j’ai arrêté, que je me suis

remis à mon compte, ça m’a fait un bien fou de passer du temps chez les clients,

de reprendre le temps de comprendre comment ils prennent des décisions,

pourquoi ils ont des problématiques différentes des autres,

et de les comprendre correctement.

Ça m’a vraiment fait un bien fou, parce qu’entre les équipes commerciales

et les équipes à gérer chez WeLoveDevs, j’avais plus de contact avec le…

En fait, ce que nous expliquent dans cet épisode Ben et Alexis,

c’est qu’on peut continuer à développer,

continuer à être un bidouilleur, un fixeur, un bricoleur, si vous…

Mais aujourd’hui, du coup,

il y a plus de raison de pas avoir le contact avec le client.

Parce que l’IA… Parce que l’IA nous donne le temps de le faire. Pendant

que mon agent tourne, je peux aller voir le client pour discuter avec lui, pour

réfléchir à son besoin, et on va itérer plus vite. Et ça, je trouve ça excitant.

Mais je garde à l’esprit qu’on aura tous une raison différente

de trouver de l’intérêt dans ce métier. Et elle sera forcément différente

si tu bosses à la Banque Populaire ou si tu bosses chez Capgemini,

par exemple. On va tous trouver des raisons différentes.

J’imagine même que dans des grandes entreprises, il y aura plusieurs versions

du métier de développeur et on va trouver des intérêts, tous les uns les autres,

différents dans le métier. Et c’est ça qu’on va explorer dans ce podcast-là.

Je serai content de faire plus d’interviews en ce sens-là.

Bref, si vous voulez venir me faire changer d’avis,

les épisodes de Fissure sont là pour ça.

N’hésitez pas à me proposer d’intervenir avec votre thèse, à m’envoyer un email.

C’est [email protected]. Envoyez-moi un email avec votre thèse,

l’épisode sur lequel vous voulez réagir, et on organise ça. À bientôt !