Entretien avec l’équipe de Kabeen, juillet 2026. Deux développeurs, un designer, un profil touche à tout. Personnes anonymisées. Rien d’original, mais c’est utile de poser cette nouvelle façon de fonctionner pour prendre date et voir dans 6 mois où nous en sommes.

Ça a tout changé

PABLO : Hier, j’ai discuté avec un copain architecte et il me parlait un peu de ce qu’il croisait comme questions, comme soucis. Il est très rigoureux en amont, peut-être trop. Et il se pose des questions sur l’impact de l’IA sur le développement. Qu’est-ce que ça a changé pour vous, tout d’un coup, d’avoir l’IA au milieu ? Je sais déjà qu’il y a beaucoup plus de branches qu’avant par exemple ?

DEV 1 : Ben, ça a tout changé.

PABLO : Ça a tout changé, c’est-à-dire, dans les faits, concrètement ?

DEV 1 : Dans les faits, concrètement : avant, tu prenais la peine de réfléchir à comment régler un problème, et de le régler. Là, en fait, t’as juste à te poser un peu la question de comment tu vas faire un truc. Et à la place, t’orientes l’IA vers ce que toi tu veux faire, et t’es plus trop à toucher au code, concrètement.

PABLO : Tu as juste à le comprendre, ou tu n’as même plus la peine de le comprendre ?

DEV 1 : Le code ? Si, si, si. Justement, c’est là où je te dis que tu l’orientes un peu. Moi, j’ai tendance à l’orienter techniquement.

PABLO : Tu ne dis pas juste « je veux que tu fasses ça, je veux avoir ça comme résultat ».

DEV 1 : Je ne lui dis pas « je veux ça comme résultat, tu te démerdes ».

PABLO : Mais tu donnes les pistes de ton raisonnement…

DEV 1 : Je donne les pistes du raisonnement, c’est ça.

PABLO : …et lui, il fait toute la suite du raisonnement.

DEV 1 : Et j’interviens souvent techniquement, en lui disant : il faudrait peut-être faire ça comme ça.

PABLO : Tu vas relire le code derrière ? Tu fais partie des gens qui continuent à lire le code ?

DEV 1 : Ça dépend, en vrai, ça dépend. Oui, quand c’est des trucs assez importants, on va dire. Quand c’est des trucs purement visuels, bon, tu testes, et puis voilà.

PABLO : Donc ça, c’est dans ton travail à toi tout seul. Et avec les autres ? Est-ce que ça a changé quelque chose dans ton travail avec les autres, ou tu travailles de toute façon isolé sur ton morceau de code ?

DEV 1 : En vrai, ça n’a pas changé grand-chose.

Des branches plutôt qu’un tronc

PABLO : J’entendais que maintenant vous avez plein de branches, alors qu’avant c’était un tronc ?

DEV 1 : Avant, c’était tout sur dev, on développait au même endroit.

DEV 2 : Je pense pas que ce soit lié complètement à l’IA.

DEV 1 : Non, je pense pas non plus.

ToucheATout : C’est la maturité, je pense.

PABLO : C’est la maturité, ouais. Donc la maturité vous a fait basculer sur des branches. Sur tous les sujets ? Une story, une branche, grosso modo ?

DEV 1 : Ouais, c’est ça.

PABLO : Et c’est pas lié à l’IA ? Moi je pensais que c’était lié à l’IA, à la puissance de production de l’IA.

DEV 2 : Alors si, c’est un peu lié, parce que du coup on produit plus, ça crée plus d’entropie et de bordel dans le code. Et notamment le fait qu’on puisse choisir maintenant l’environnement de développement… Avant, c’était un truc stable qui pouvait partir en prod ; on devait essayer de trouver une espèce de fenêtre de tir où tout le monde arrêtait de travailler pour dire « c’est bon, on pousse en prod ce qui est sur les branches ».

PABLO : Ah, et maintenant c’est plus nécessaire, ça ?

DEV 2 : Parce que comme on se base sur des branches, elles sont poussées, il y a des environnements prévus sur ces branches. Et quand on dit « c’est OK », on la merge dans develop. Et à tout moment on peut déployer develop.

DEV 1 : Quand ça passe de functional review à production ready, c’est qu’on la merge.

PABLO : Mais les gens se plaignent beaucoup avec l’IA, dans ce que j’entends, dans pas mal de projets autour : comme l’IA est capable de développer plein de choses — production excessive, à outrance —, t’as un problème de merge et de réconciliation. On fait travailler l’IA là-dessus, ou on n’a pas de problème avec ça ?

DEV 1 : Moi, je sais que pour régler les conflits, par exemple, il fait tout, il le fait très bien. À la limite, il me pose des questions légitimes sur ce qu’on veut garder par rapport à ce qui est en conflit. Mais sinon, il se débrouille vraiment. Ce qu’il préfère, c’est régler les conflits entre plusieurs branches.

PABLO : On a des outils dédiés là-dessus, ou il le fait tout seul et on l’interroge comme ça ?

DEV 1 : Il le fait tout seul, il y a juste…

PABLO : Avec Git. Donc ça n’a pas changé fondamentalement, c’est juste tombé au même moment. Il y a des choses qui sont liées à l’IA dans le changement, dans le flux de fabrication ?

La fin de l’estimation

DEV 2 : Il y a la difficulté qui est… Alors, déjà, avant c’était dur, mais je trouve qu’il y avait un côté exponentiel dans la difficulté d’une feature, d’un ticket, d’un truc à implémenter, qui faisait qu’on arrivait à peu près mentalement à se dire : ce truc va être très dur, ce truc va être moyennement dur, ce truc va être très simple.

DEV 2 : Aujourd’hui, c’est devenu très linéaire. Enfin, c’est pas constant, la difficulté, mais un truc qui était excessivement difficile, c’est presque le même temps qu’un truc normal ou pas très dur, tu vois.

PABLO : D’accord, je vois bien.

ToucheATout : Alors, si on parle de Scrum, tu vois…

DEV 2 : La notion de poids d’effort, elle n’a plus le…

ToucheATout : …plus le même sens, en fait.

PABLO : Tu veux parler de Scrum, mais on est plutôt dans le no estimate, ça. On pourrait dire que ça ressemble au no estimate : 0, 1, ou « j’en sais rien ». Il n’y a plus d’échelle, quoi.

DEV 2 : Et puis il y a des trucs qui vont être un peu longs, mais tu sais pas trop pourquoi. C’est difficile à anticiper.

Le temps passé à tester

DEV 2 : Alors moi, c’est très perso, et comme il a parlé un peu de ses impacts sur lui tout à l’heure : c’est le fait que du coup, je passe beaucoup de temps à tester maintenant. Enfin, j’ai l’impression que le gros de mon travail, c’est de tester ce que l’IA a pu produire.

DEV 2 : Si on prend toute la phase de dev : avant, il y avait 50 % de dev, 50 % de tests, dans ce que tu faisais dans une journée. J’implémentais un truc, ensuite je faisais des conditions pour le tester, et je vérifiais que ça marche dans les edge cases.

DEV 2 : Non, la première partie, elle a drastiquement réduit — c’est la production du code. Par contre, le test, il est toujours là. Il faut toujours faire les edge cases à la main, il faut toujours trouver…

PABLO : Et le test, il a changé de façon de faire ? Parce que je te vois lancer quand même des Claude qui analysent la plateforme ou le code.

DEV 2 : Oui, en tout cas il m’a permis de faire des tests à des ampleurs qu’avant je ne pouvais pas faire.

PABLO : Quel type d’ampleur ? La couverture fonctionnelle ou la somme de données ? Ou les deux ?

DEV 2 : Les deux. C’est-à-dire, aujourd’hui, par exemple, quand on fait le travail sur l’infra, je peux en trois minutes lancer plein de VM qui vont faire plein de trucs pour simuler nos agents, des trucs comme ça — parce qu’avant, ça m’aurait pris beaucoup de temps. Ou je peux faire aussi pas mal de scripts d’analyse des données qu’on a ingérées.

DEV 2 : Genre, je veux vérifier quelque chose — je l’ai fait tout à l’heure : je voulais vérifier la quantité de données que produisent les agents sur les réseaux, et me faire à peu près une estimation de, si je change l’architecture, de combien ça va faire baisser cette donnée, en pourcentage. Et du coup, je peux facilement tester là où avant c’était un peu complexe : il m’aurait fallu plusieurs jours pour tester, là ça m’a pris genre cinq minutes.

DEV 2 : Donc, de mon point de vue, je suis devenu un peu le goulot d’étranglement. En fait, c’est ma capacité à moi à paralléliser les tâches, à imaginer, qui devient le point bloquant, et non plus le reste.

Faut-il recruter versus puissance de l’IA ?

PABLO : D’autres trucs que vous voyez qui ont changé avec l’IA ? Est-ce que vous auriez dû embaucher quelqu’un ? Vous n’avez pas embauché quelqu’un ?

DEV 2 : Oui, clairement. Je pense qu’on peut produire aujourd’hui ce qu’on n’aurait pas pu produire à l’époque…

PABLO : Vous êtes 4 et vous testez, c’est fois 2 minimum, là ?

DEV 2 : C’est plus que ça, c’est difficile à mesurer, mais c’est plus que ça : c’est fois 4, fois 5 minimum.

DEV 2 : Aujourd’hui, je peux prendre à moi tout seul deux ou trois gros projets en parallèle.

DEV 2 : J’ai une autre estimation : c’est le premier agent qu’on a fait. J’ai mis à peu près, je pense, entre la première ligne de code et le truc qui tenait bien la route, entre 3 mois pour une première version et 6 mois pour avoir un truc qui était à peu près solide en production. Je pense que le deuxième agent serveur, quand on l’a refait, ça m’a pris une semaine.

PABLO : Oui, mais là tu ne parles pas d’estimation, tu parles de puissance de fabrication, de delivery. Là, ça donne une idée : on est passé de 6 mois à une semaine.

DEV 2 : Alors, évidemment, entre-temps j’ai accumulé pas mal d’expérience. La première fois, je montais en compétence sur le langage, etc. Donc ce n’était pas forcément la bonne référence.

Spécialisation, full-stack et t-shape

PABLO : Et est-ce que ça vous a spécialisés ? Est-ce que finalement tout le monde se met à faire du design, ou est-ce que — parce que Claude — tout le monde fait du code ? Ou est-ce qu’au contraire vous avez gardé votre spécialité, vous êtes allés plus loin dans votre spécialité ?

DEV 1 : Je pense que c’est plus que tu gardes ta spécialité, en vrai. Moi, je suis toujours nul en design, et même avec l’IA je pense que ça ne changera pas. Parce que moi, je n’ai pas la capacité de dire « ça, en design, c’est de la merde », tu vois.

PABLO : Ça pourrait être : par exemple, tu ne bossais que sur les agents, et maintenant tu bosses sur… je ne sais pas. Tu sais, tu as les front, tu as les back. Avant, tu avais les dev front, les dev back, les dev mobile. Peut-être que maintenant, un dev, il s’en fout que ce soit mobile, agent, front, back : si c’est du raisonnement, il peut tout attaquer.

DESIGN : Après, ici, vous avez toujours été full-stack, en vrai.

DEV 1 : Oui, on a toujours été full-stack.

Le niveau stagne

DEV 1 : Je n’ai pas l’impression d’avoir développé… Justement, j’ai l’impression que mon niveau a stagné depuis que j’utilise l’IA, tu vois.

PABLO : Ah oui, tu as un problème. Ton raisonnement, c’est celui que tu avais avant l’IA. Elle te nourrit, l’IA, en apprentissage, ou pas ?

DEV 1 : Non. Honnêtement, non. Peut-être que j’apprends certains trucs qui sont cool en dev, mais en réalité, non.

PABLO : Est-ce qu’on retombe encore sur des merdes qu’on ne sait pas résoudre, et où on se dit qu’on ne saura jamais les résoudre ? Avant, en dev, on se disait : putain, ça, on ne saura jamais le faire, ça va nous demander de changer à 10 000 endroits — et puis finalement, non.

DEV 1 : Moi, je me dis : au pire, je sais que j’y arriverai, tu vois. Parce que j’ai quand même fait quelques années en dev, et je sais qu’il y a souvent eu des problèmes qui paraissaient insurmontables et qui, au final, ont été surmontés.

PABLO : Quoi qu’il arrive.

DEV 1 : Donc je pense que si l’IA disparaît demain, je n’aurai aucun problème.

PABLO : C’est juste l’accélération qui change.

DEV 1 : Oui, c’est ça. C’est la vélocité, pour moi.

Et si l’IA disparaissait demain ?

PABLO : Et si l’IA disparaît demain, tu as toujours envie de développer, ou ça fout trop le bourdon que ça aille tout d’un coup dix fois plus doucement ?

DEV 1 : Ça, c’est ce que je me suis demandé. En vrai, je pense que ça va beaucoup impacter, parce que ça va être un retour en arrière. Mais d’un autre côté, ça permettra de se reposer des questions qu’on se posait il y a quelques années, tu vois. Peut-être de plus réfléchir à « est-ce qu’on devrait faire telle ou telle feature ? ».

La tentation de tout produire

DEV 1 : Là, je pense que pour moi, le premier problème avec l’IA…

PABLO : On n’y réfléchit pas, là ? À telle ou telle feature qu’on doit faire ?

DEV 1 : Disons qu’en fait, j’ai l’impression que comme on a une capacité de dev qui est immense, tu vois, on a moins tendance à… Vu que ça demande beaucoup moins d’efforts de faire une tâche, on va se dire : bon, on la fait, et puis voilà. Alors qu’avant, on ne pouvait pas se dire « vas-y, on fait ce truc » — j’en ai pour deux mois, tu vois, je me lance comme ça à l’aveugle.

PABLO : Dans les apps, il y avait déjà beaucoup de problèmes d’obésité, de fonctionnalités qui ne servaient à rien. Donc là, vous l’avez mesuré, qu’il y a beaucoup plus de lignes de code, beaucoup plus de fonctionnalités ?

DEV 1 : Je dis pas que c’est vraiment le cas actuellement.

DEV 2 : Ça permet d’enlever aussi pas mal. Enfin, moi, j’en fais pas mal : je chasse du dead code, des trucs comme ça, il le trouve bien.

L’IA qui enfume

DEV 2 : Alors après, il y a pas mal d’aspects, quand même. Il y a des tâches qui sont répétitives : c’est des patterns qu’on a déjà implémentés dans l’appli et qu’on veut juste répliquer pour d’autres notions. Par exemple, tu as une notion que tu gères dans l’appli, et tu veux créer une notion sœur qui se gère à peu près de la même manière. Là, l’IA, elle est hyper performante, parce qu’elle a déjà l’exemple : elle ne fait que copier le truc, elle connaît la manière dont tu l’as implémenté, donc elle va le réimplémenter exactement de la même manière. Donc tout ça, c’est devenu hyper simple, et il n’y a même pas besoin de se poser de questions.

DEV 2 : Après, sur les autres sujets, il y a quand même plusieurs effets. Je pense qu’on se laisse aussi un peu impressionner, parfois, par ce que l’IA donne, parce qu’elle utilise des termes qui nous semblent savants mais qui, au final, sont des patterns qu’on connaît en tant que développeur, tu vois. Et donc elle fait un peu de l’enfumage, en mode « j’ai fait un truc incroyable » — alors qu’en fait, ce n’est pas du tout fou. C’est juste dans la synthèse qu’elle te donne : elle utilise des mots qui donnent l’impression qu’elle a fait des trucs incroyables, mais en fait, quand tu regardes, c’est un peu nul, ce qu’elle a fait.

DEV 1 : Surtout quand tu parles en français, tu n’as plus besoin des termes qui sont…

DEV 2 : Et donc, en fait, pour ne pas avoir peur non plus de perdre pied : elle fait des choses qui ne sont pas hyper complexes. Et souvent, je trouve qu’elle n’est pas très bonne pour être…

PABLO : Normalement, ce n’est pas fait pour faire des choses complexes, parce que c’est de la probabilité par rapport à tout ce qui a été écrit.

DEV 2 : Oui, mais bon, on voit aussi des effets de bord où elle arrive à être créative. Je trouve qu’elle n’est pas hyper créative. Et donc je suis toujours quand même dans un état d’esprit où, d’abord, moi, je réfléchis à comment je résoudrais le problème, mais de manière macro. Et après, dans le détail, je lui laisse le choix d’implémentation. Mais par contre, je lui donne complètement la guideline sur là où je voudrais qu’elle aille.

Passer à 10-15 développeurs

PABLO : Là, vous dites que, grosso modo, votre puissance de feu est passée de 4 à 10, 20 personnes. Donc l’équipe n’est plus (si elle l’a été) le point bloquant.

DEV 2 : Je n’ai pas l’impression qu’aujourd’hui, ce qu’on attend le plus, ce soit sur eux. Je pense que faire maturer l’idée de ce qu’on aimerait vraiment dans la plateforme, le designer…

PABLO : C’est ça qui devient le point bloquant. C’est ce que disent les boîtes actuellement : le plus dur, c’est ça. Et après, comment on l’implémente ?

DESIGN : C’est normal. Comme tu l’as dit, vous passez de 4 développeurs à… genre une dizaine.

DEV 2 : 10 ou 15 développeurs.

PABLO : Ce que j’entends beaucoup, c’est, tu vois, Linus Torvalds ou autre : ils se plaignent maintenant d’un flot de difficultés, de réconciliations, et tout. Vous ne semblez pas du tout en souffrir.

DEV 2 : Parce qu’on n’est pas nombreux. Et nous maîtrisons très bien la plateforme.

PABLO : Vous êtes 4 et on estime que c’est +10 en développement.

DEV 1 : Après, il y a quand même des choses, c’est juste qu’on ne le dit pas à tout le monde. Par exemple, là, j’ai eu un problème de migration il n’y a pas longtemps : j’avais 4 migrations de retard. Mais bon, ça, c’est des trucs qui arrivent. Après, ce n’est rien du tout, ça.

PABLO : Et ça, c’est l’IA qui te le prend et te le résout.

DEV 2 : Oui. Juste, Linus, il est au cœur d’un truc où il y a beaucoup, beaucoup de contributeurs.

PABLO : Linus, ça se compte en milliers. Ce n’est pas la même échelle. Et puis tout le monde veut son petit moment de gloire.

DEV 2 : Par contre, si là, on se retrouvait à 10 développeurs dans l’équipe, avec la puissance de dev qu’on a aujourd’hui par développeur, je pense qu’on aurait un problème.

PABLO : Je pense qu’on aurait intérêt à ne pas faire grossir l’équipe, à faire une autre équipe à côté. Et la difficulté, c’est le découpage de l’objet produit : comment tu le découpes pour qu’il vive ?

DEV 2 : En fait, on va avoir du mal même à savoir ce qu’on veut mettre… Je pense qu’on nourrirait cette équipe de développeurs, je pense qu’on n’aurait pas de mal.

PABLO : Non, on n’aurait pas de mal, malheureusement. Et malheureusement, parce qu’effectivement il y a des effets d’inutilité, d’obésité.

DEV 2 : On ferait des trucs inutiles, c’est plutôt ça. On aurait tellement la possibilité de tout faire que du coup, on ferait des trucs inutiles.

PABLO : Là, ce qui est drôle, c’est presque qu’il faut que le client réussisse à suivre le rythme.

DEV 2 : Ils en ont marre, ça va trop vite.

Généraliste et communication avec l’IA

DEV 2 : Je voudrais rebondir sur ce dont il a parlé pour lui, sur l’aspect full-stack. Moi, comme j’étais plutôt un mec un peu touche-à-tout en dev, sur plein de domaines très différents, du coup ça m’a juste rendu très bon dans plein de domaines différents. Enfin, ce n’est pas moi qui suis très bon, du coup : c’est juste que comme je suis plutôt un généraliste, où je fais plein de trucs différents, j’ai la capacité à être bien meilleur dans chacun des domaines, alors qu’avant j’étais un peu limité.

PABLO : Oui, c’est ce qu’on appelle les t-shapes ou autre, quoi.

DEV 1 : En fait, je pense que ce qui a été amélioré, du coup, c’est ta capacité à communiquer avec l’IA, plus qu’à développer, tu vois. Moi, c’est ça où je me suis amélioré. Ce n’est clairement pas le dev, puisque le dev, je n’en fais plus.

PABLO : Tu n’en fais plus, du dev ?

DEV 1 : Ben non, quasiment plus. Enfin, sauf pour des trucs…

PABLO : C’est pas parce que tu appelles ça le dev, mais écrire du code.

DEV 1 : Écrire du code, oui.

PABLO : Alors qu’est-ce qui m’empêche, moi, de toucher le code de l’appli ?

DEV 1 : Ben, la connaissance, j’imagine.

PABLO : Le raisonnement de développement.

DEV 1 : Le raisonnement du développeur.

PABLO : OK, je vais développer pendant les vacances, alors.

DEV 2 : La vérif, je pense.

DEV 1 : La vérif. Et il y a quand même des trucs où il est nul encore. Genre le visuel, par exemple.

PABLO : Oui, parce que ce n’est pas du langage.

DEV 1 : Oui, c’est ça. Donc, l’interprétation. Et tu as toujours besoin, je pense, d’un développeur pour ça, tu vois. Parce que ce n’est pas n’importe quel mec qui peut… Déjà, qui connaît les termes techniques pour le front ou quoi, tu vois.

Le coût

PABLO : Et au niveau des coûts, ça nous coûte combien versus embaucher un dev ? Pour l’instant, on y gagne vachement. Je commence à entendre que des boîtes commencent à s’essouffler.

DEV 1 : Il y a pas mal de boîtes qui abandonnent Claude.

PABLO : Il y a eu des trucs comme ça, oui. Ou ça commence à leur coûter trop cher. Nous, on en est très loin.

DEV 2 : On ne crame pas trop notre abonnement. Enfin, on est tous avec Claude. C’est quoi ?

PABLO : Oui, c’est un Claude Pro.

DEV 2 : C’est quoi, c’est 90 balles par mois, non ?

DEV 1 : 100 euros, je crois. 100 balles par mois.

PABLO : Donc on est très, très loin du coût d’un dev, quoi.

ToucheATout : Et puis, les trucs qu’on entend, c’est les boîtes qui, au-delà de 150 (euros par mois), ont un problème. Parce qu’au-delà de 150, tu es obligé de passer sur le plan API.

ToucheATout : Tu ne peux plus avoir ton plan à 100 balles.

DEV 2 : Au-delà de 200 balles, si tu mets 200 balles supplémentaires, tu n’as pas du tout la même capacité.

Les limites, le contexte, le prompt

PABLO : Vous arrivez au bout de votre abonnement ? Moi j’ai le Claude Max, là, je n’arrive pas au bout. Vous y arrivez, au bout, vous ?

ToucheATout : Là, aujourd’hui, j’ai tapé la limite, mais c’est… c’est rare.

DEV 2 : C’est rare. Moi, ça ne m’arrive plus parce que, finalement, comme je te disais, je passe beaucoup de temps à tester. Donc je fais une grosse session de code, et après je passe beaucoup de temps à tester ce que j’ai fait.

DEV 1 : Je pense que c’est là, la différence entre un dev et quelqu’un qui n’est pas technique, tu vois.

PABLO : Oui, il va boucler, boucler, boucler, et cramer du token.

DEV 1 : J’imagine que quand tu fais un truc, tu vois, tu vas lui parler d’une façon assez simple, sans entrer trop dans le technique.

DEV 1 : Pas con, mais sans rentrer dans le technique, parce que le truc technique, tu ne le connais pas, tu vois. Technique dev, je veux dire.

DEV 2 : Et en plus, il y a le risque, en lui parlant comme ça, que c’est là où les IA se mettent à déconner. Au bout d’un moment, le contexte ne veut plus rien dire, parce qu’il a fait plein de circonvolutions dans tous les sens. Et il commence à déconner à ce moment-là.

PABLO : Tu le /clear souvent, ton contexte, toi ?

DEV 2 : Très souvent. À chaque fois que je change de sujet, je /clear.

PABLO : Moi, ça m’est arrivé beaucoup… Oui, mais après, c’est ton cerveau. Moi, je mélange les sujets, et au bout d’un moment il m’a dit « arrête ». C’est pour ça que les « by the way » sont arrivés, tu vois. Pour des mecs comme moi qui…

DEV 1 : Je te disais : moi, ça m’est arrivé très, très souvent qu’en vrai, en un seul prompt, c’est parfait, tu vois. Parce que le prompt, je l’ai guidé, vraiment…

PABLO : Oui, toi, tu fais des gros prompts, alors.

DEV 1 : Moi, je fais des gros prompts, tu vois. Je prends un ticket Linear et je développe, tu vois, en lui demandant techniquement ce que je veux. Donc, des fois, j’ai des prompts qui font genre 50 lignes, 60 lignes, et à la fin c’est quasiment parfait, tu vois.

PABLO : Moi, c’est l’inverse, tu vois : je fais des prompts d’une ligne.

Design system et automatisation

PABLO : Tout ça, ça me semble très classique, mais c’est bien de se le redire. C’est quoi, le prochain truc qu’on fait avec l’IA qu’on n’a pas encore vraiment fait, qu’on n’a pas osé faire, là, aujourd’hui ? J’ai ma petite idée, j’ai une proposition, moi, mais… Sur la plateforme, c’est sûr. Peu importe : ça peut être la formation pour les utilisateurs, ça peut être celui qui tient Linear, ça peut être celui qui dialogue avec les users, ça peut être un morceau du code.

DESIGN : En tout cas, moi, là où je vois l’avantage — parce que je vois très bien qu’à un moment je ne pourrai plus suivre la vitesse des développeurs —, c’est d’arriver à automatiser, notamment à travers des systèmes, énormément de tickets qui ne demandent pas, finalement, beaucoup de travail, si ce n’est de pouvoir poser des maquettes, tu vois ? Et de pouvoir m’affranchir, des fois, de certains petits trucs qui étaient à la base réservés aux designers juniors.

PABLO : Oui, tu es en train de dire que si tu avais un design system, l’IA pourrait le traiter toute seule.

DESIGN : Oui, grosso modo, c’est ça. Parce que je pense que c’est une question de maturité — c’est exactement pareil que pour les PR. En fait, en réalité, si j’avais dû faire un design system dès le départ, je pense qu’on aurait été vachement dans la merde, et j’aurais été vachement moins efficace. Aujourd’hui, je pense qu’on a suffisamment de matière pour pouvoir en créer un qui soit pertinent. À l’époque, ce n’était pas le cas.

PABLO : Ce n’est pas le moment où on a inversé, où on doit avoir plus d’UX/UI que de dev ? Tu ne vas pas proposer ça, d’embaucher des UX/UI en plus ?

DESIGN : Si, je pense qu’il y a un moment où il faudra.

DEV 2 : Oui, ça serait plus pertinent.

Le design et la boucle de feedback

ToucheATout : La prochaine étape de Claude, c’est qu’il n’est pas assez bon en design, parce qu’il n’a pas tellement accès à l’écran.

PABLO : Ah oui, Claude design, vous avez creusé ?

ToucheATout : Je ne suis pas si satisfait que ça pour l’instant.

ToucheATout : Claude design, en général, n’est pas extrêmement utile, ce qui fait qu’il y a encore beaucoup de travail à faire. « Fais-moi une interface 2.1, dans la continuité de notre plateforme » : ce n’est pas mieux.

PABLO : Oui, c’est des LLM, donc c’est de la probabilité. Donc en code, c’est parfait, parce qu’il réplique le code du monde entier qui fonctionne. Dans le design, il réplique le truc, mais on s’en fout.

ToucheATout : Ils peuvent tout vérifier sur le code, ils peuvent vérifier que ça marche.

PABLO : Oui, tu as raison : tu as la boucle de feedback qui est morte.

ToucheATout : Ils ne peuvent pas savoir si c’est bien ou pas.

DEV 2 : Oui. Ça marche particulièrement bien en Rust — pas parce qu’il est fort en Rust, mais parce que la feedback loop est super courte. Dès qu’il produit une ligne de code, il compile. Du coup, quand il voit que ça ne compile pas, il itère jusqu’à ce que ça compile. Et quand ça compile, normalement ça marche. Et c’est là où je suis content qu’on ait des langages fortement typés dans tout ce qu’on fait, parce que ça nous permet justement d’être assez forts.

DESIGN : Et le design, c’est un peu particulier. Je pense que pour faire du design standard, c’est OK — je pense qu’il y a énormément de devs qui sont satisfaits de ça. Quand on parle de projet, c’est OK. Mais avec l’idée qu’on se fait de notre produit, et de la gueule qu’il doit avoir, il y a un petit truc qui bloque encore.