guillaume-st-etienne-larchitecture-vue-par-un-dev-de-2026

[00:00:00] On va avoir du son ? Du son, du son. C'est bon, super.
[00:00:12] Un, deux, trois. Un, deux, trois. Oui, ça parle. Oui, c'est bien.
[00:00:48] C'est toi qui gère mon temps ? Je fais bien.
[00:00:52] Tu gères tout?
[00:00:55] Je vais mettre peut-être...
[00:01:07] 5. 45? 45 minutes. Ok, dans ton groupe, ça donne 2 tours par rapport à 40? Oui, je vois bien.
[00:01:18] Je vais essayer de déjà tenir mes 45 minutes.
[00:01:22] Oui, ça marche.
[00:01:25] Allez, donc, re-bienvenue.
[00:01:29] Merci les organisateurs Flocon, merci les sponsors. Je n'ai pas de slide sponsor, mais sans eux, les conférences ne pourraient pas se faire.
[00:01:41] Je suis Guillaume Saint-Etienne, je vais vous parler d'architecture. C'était le sujet qu'on m'a proposé de faire spécialement pour AlphaCode. Mon architecture pour les devs, vu par un dev, je suis parti, j'ai jugé parti. Du coup, mon avis vaut ce qu'il vaut. Je vous dirai la fin.
[00:02:02] J'ai la chance de travailler depuis 10 ans et demi sur le projet Hyper. Je suis externe, mais je suis tellement fier de ça que je le mets dans tous les salles. Et justement, que ce soit Hyper ou dans l'architecture logicielle ou dans l'architecture civile, on est là pour construire des choses et a priori, pour qu'elles durent. C'est un peu l'idée. D'où le rôle de l'architecte est connu depuis... assez longtemps, on va dire, depuis qu'on construit du solide ou semi-solide, peu importe le style, peu importe la vocation.
[00:02:46] Quant à construire du logiciel, des gens s'y essayent depuis longtemps. On a des pères fondateurs qui ont pensé d'abord les ordinateurs et ensuite ont essayé de les réaliser. C'était un peu simple au début, mais toute la théorie, tout le questionnement, même philosophique, était là.
[00:03:09] Et j'aime bien citer Alain Turing pour le rôle particulier qu'il a pu avoir dans l'histoire et comment l'histoire l'a un peu maltraité quand même, même s'il a été réhabilité, heureusement, relativement récemment.
[00:03:22] Pour ma part, je ne suis pas Alain Turing. J'ai vu certainement de choses passer entre mes premières lignes de code ici sur cette drôle de machine avec son extension 64 kilo octets de mémoire et un clavier immonde. Il devient foncé comme ça, pour que ça prenne en compte le caractère que vous voulez avoir.
[00:03:48] Jusqu'à aujourd'hui, je pense comme tout le monde, Voyons, qui n'utilise pas ces outils-là? Ça va aller plus vite. Très bien. Merci de votre franchise.
[00:03:59] Construire, c'est une ligne. une dynamique sans cesse en renouvellement, ce n'est pas l'industrie logicielle, le métier du logiciel qui fait ça, c'est plus la société dans laquelle on baigne, et ça a été théorisé, alors je ne vais pas mettre Marx
[00:04:18] sur une image de présentation, mais si, parce que c'est revenu un peu d'actualité avec les prix.
[00:04:25] Les prix Nobel d'économie récents qui nous reparlent effectivement de construction destructrice et destruction créatrice, les deux s'enchaînent. Et nous aussi, et encore plus rapidement, ça s'accélère évidemment depuis l'IA générative, où on est en train de tout péter en même temps qu'on pense tout reconstruire.
[00:04:50] Le rôle des architectes pour construire tout ça, il est connu, il est documenté, et c'est une affaire de position. Donc, les architectes, ce sont des gens qui se sont positionnés, qui venaient en général du dev. Des gens à qui on a promis d'ailleurs un futur meilleur en devenant architecte, parce que vous comprenez, on ne peut pas rester d'être toute sa vie. Soit tu deviens manager, chef, soit il reste quand même une place, si tu veux faire encore un peu de tech, en architecte, architecte d'entreprise. Mais les architectes d'entreprise se sont bardés, on va dire, de tout un tas de... Pratique de framework, de cérémonie, un peu pour asseoir une position un peu dominante auprès de ce qu'ils étaient avant de la simple règle.
[00:05:41] Vous avez le droit de ne pas être d'accord. Et il y a d'autres architectes qui se disent, nous, on veut rester un peu plus proche de ce qu'on produit, un peu moins dans les hautes sphères et dans les bureaux, et être un peu plus sur le chantier. D'où leur nom. Craft Architect, c'est moi qui ai sorti ça. Mais ça se retrouve sur la façon un peu de travailler. On va y avoir les architectes qui ont plus piloté par des métriques plutôt quantitatives, des tableaux de bord, on ne pensait pas, c'est un peu Excel, plutôt orienté sur la mesure de la productivité, sur la gestion du temps, les prévisions, les plannings, etc. Des vélocités en veux-tu en voilà versus ceux qui sont plus... Et des fois, ça peut être la même personne, après tout. Même dans le cas où ils vont essayer de faire des architectures et de référer à des personnes qui font autorité, par exemple, certains en pleuvent, enfin qui faisaient autorité plutôt. Le bouquin n'a pas forcément bien vieilli, tout n'a pas forcément bien vieilli dans ce bouquin. Et même des gens armés de ce bouquin sont revenus à dire, j'ai quand même besoin de métriques, il me faut des chiffres, je vais piloter par les chiffres. Donc je vais remplacer mes dashboards et mes tableaux. d'autres dashboards avec d'autres. Notamment, on va reparler de cette histoire de dette, par exemple.
[00:07:13] Donc voilà comment on voit souvent l'architecte, le fameux architecte Tour d'Ivoire. Cette image parle et continuera à parler parce que, bon, même si elle a été générée par hier, ça va, ça va.
[00:07:28] dessous, au pied de la tour, il y a de moins en moins d'humains, du coup, de plus en plus d'agents. Au moins, des humains qui supervisent les agents, quitte à ce qu'à un moment, l'architecte se retrouve tout seul avec ses agents.
[00:07:45] Cette place Tour d'Ivoire, elle est entretenue par un certain nombre de croyances,
[00:07:57] de choses communément admises, voire de choses que les entreprises vont acheter, vont acheter du conseil auprès de cette méthodologie-là, de ce framework méthodologique-là, qui place les architectes toujours en position d'ultra-décideurs, au même titre que les business owners. Et pas trop dans l'équipe, alors que Safe, on dit beaucoup de mal de Safe, moi le premier, mais il y a quand même un truc marrant ici, tout le monde a oublié, c'est qu'il préconise la built-in quality. La qualité intégrée, elle est dedans, elle est censée rayonner, c'est marqué« essential». Alors, comment le truc est essential? Moi, je le trouve un peu relégué au coin.
[00:08:47] C'est une histoire de point de vue.
[00:08:50] Et donc, ces architectes-là sont des architectes, pour moi, du business. Ils sont très connectés au business. Ils pensent business, ils respirent business, ils brassent du business et ils font des modèles, ils adorent faire des modèles, des super modèles de tout. Toujours avec du business de partout. Et ils ont raison, d'une partie, il faut du business. bien nous payer, déjà, nous, les gens qui le faisons. Mais on en vient des fois à des trucs un peu extrêmes, pour le coup.
[00:09:24] Or, je pense que construire du logiciel, architecte ou développeur, on devrait se placer dans une dynamique qui inclut du business, mais pas que. Dynamique qu'on pourrait résumer en trois points, que vous connaissez, je pense. Construire la bonne chose.
[00:09:42] Le construire bien, la bonne façon, disons d'une pas trop mauvaise façon, et je rajouterai avec les bonnes personnes.
[00:09:52] Ça va devenir intéressant. Donc, construire la bonne chose, c'est le produit, le bon produit. Pour décider de ce qui est le bon produit, on fait appel à des product management, des gens qui savent mieux que les architectes ou qui n'en mettent pas en cause leur... Leur connaissance, leur savoir, leur expérience.
[00:10:15] Ils sont connectés à la fois aux gens qui vont faire le delivery, qui vont construire, et à toutes les autres parties prenantes. Ils sont vraiment clés, ils sont vraiment importants. Sauf qu'ils ont une petite fenêtre de connexion avec nous qui est quand même un sixième du problème, seulement.
[00:10:34] Et on peut avoir, du point de vue des équipes de développement, cette légère sensation quand même d'être bien gentil, mais de rester bien à sa place.
[00:10:45] Et obéissant, bien sûr.
[00:10:49] Pourtant, les gens du produit, ils ne sont pas bêtes. Ils ont quand même abandonné le cycle de vie en V, les trucs trop descendants. Ils sont plus dans... Vous êtes plus... Il y a des gens du produit ici. Moi, je ne l'ai pas la main, mais... Pas comme ça. Donc, ça, vous connaissez, vous appliquez, plus ou moins, découpez, plus, à mon avis, que moins, découpez un espace du problème
[00:11:18] et passez à l'espace de la solution dans des boucles itératives courtes pour essayer, pour apprendre de l'expérience de la mise en situation, de la mise en production.
[00:11:32] Dans un effort, on y revient, de création destructrice, mais à dessein, de telle manière à s'améliorer, être plus rapide pour capter un marché et plus performant.
[00:11:53] Domaine Driven Design reprend cette idée et donne beaucoup plus, je trouve, d'éléments assez factuels sur comment, procède de la conception, de la stratégie jusqu'à la tactique, la réalisation,
[00:12:10] en éléments interconnectés qui se parlent entre eux, et donc dans lesquels le développeur a potentiellement sa place, même si on l'envoie un peu à droite du schéma, Mais il a tout à fait sa place sur la partie stratégique, puisqu'il est normalement invité sur des ateliers type event storming, impact mapping. Il a son mot à dire. Il peut aussi avoir l'équipe de dev, et pas que les architectes peuvent avoir des vues intéressantes. Qui peuvent impacter la stratégie du produit.
[00:12:49] Ce n'est pas moi qui le dis, c'est lui.
[00:12:52] C'est un monsieur que vous connaissez, peut-être pas, c'est Marty Kagan, un gars important de la CI Cone Valley, qui était venu à Paris il y a 4 ans pour la School of Product. Et moi, j'ai mangé en face du but, je ne savais pas qui c'était. On m'a dit, mais t'es fou, c'est Marty Kagan. Et après, j'ai acheté ses bouquins et après, j'ai fait, il dit vraiment des trucs intéressants, en fait, pour un mec du produit. Son truc, lui, c'est les produits. C'est les produits qui changent la vie des gens. Il a travaillé à Apple et tout ça. Et dans ce dernier bouquin, Empowered, il dit, il vous faut des ingénieurs, les équipes produits ont besoin d'ingénieurs qui ont les moyens, qui ont du pouvoir, et du pouvoir aussi, des moyens et du pouvoir de décision.
[00:13:38] Donc des gens, Empowered Engineers, qui vont construire la bonne chose et de manière bien, grâce à de la technique.
[00:13:47] Technique, si on se place du point de vue du développement, est-ce qu'on voit des techniques?
[00:13:54] Des fois, malheureusement, on ne voit pas le produit, on arrive, on est embordé dans un projet, on voit ça, on voit une code base, on voit des intéfacts, on voit des règles, on voit un wiki, une confluence, des fois un peu compliqué à suivre.
[00:14:12] Mais c'est ça, on arrive dedans, on perçoit peut-être des... les éléments si le code est pensé avec des principes de données du fameux langage bibliquitaire, bibliquitaire, bibliquitaire, mais des fois on ne l'a pas. Et en tout cas, ça c'est notre quotidien de développeur, qu'on soit développeur ou qu'on soit amené à être remplacé. Par nos copains agents. Ça procède, on travaille un peu tous sur le même terreau. D'où ce terreau, du point de vue de l'IA, ce n'est que du contexte. C'est tout ce qu'il faut pour nourrir un prompt ou pour améliorer, ou des guidelines, ou ce que vous voulez, pour que l'agent IA puisse produire un code à peu près... À peu près, c'est pas table.
[00:15:02] Et pour nous, humains, parce qu'on est encore là, ça, c'est notre fond de commerce, c'est notre culture, c'est bien plus que le contexte. C'est tout ce qu'on a commencé à apprendre, parce qu'au début, on est passé par des phases d'apprentissage, que ce soit de l'apprentissage ou dans un parcours public ou privé. Donc, les gens nous ont initiés à la culture du développement. Et cette culture, de par notre expérience, nous l'avons fait nourrir parce que nous avons ajouté nos propres pierres à l'édifice et nous avons discuté avec des gens qui avaient d'autres façons de faire. Peut-être qu'on s'est confronté aussi à d'autres façons de faire, à quelque chose qui était peut-être un peu plus rugueux. L'interaction entre humains est plus rugueuse que celle qu'on a avec les agents conversationnels, qui sont toujours d'accord avec nous, mais c'est bien le problème.
[00:15:53] Je reviendrai sur la culture plus tard. Du coup, les architectes de ces artefacts-là sont là, selon moi, pour nourrir une culture déjà basée sur la solidité de ce qu'on va produire. Solidité basée... Sur l'expertise et l'excellence plutôt technique autour de tout un tas de pratiques, je pense, qui sont assez largement acceptées maintenant, les tests, la présence des tests, leur automatisation, le fait qu'on pense... qu'on guide le design par les tests, qu'on fasse du code propre, etc. On peut mettre ça dans des pipelines de CI-CD, on ne peut pas me livrer d'avoir des boucles de feedback rapides. Tout ça, le but d'une architecture est de produire des choses qui sont censées résister au temps et donc être non fragiles, donc ne pas s'écrouler dans le temps. Ce qui est marqué à gauche, c'est généré par l'IA, ce n'est pas forcément des exemples un peu poussés, un peu techniques. Ce qui m'intéresse plus, c'est le diagramme à droite, qui ne vient pas d'architecture, qui vient de la socialité.
[00:17:10] Mais on retrouve les mêmes idées. Il faut innover pour être antifragile et il faut devancer les problèmes dans un certain nombre de cas pour pouvoir y résister. Et s'adapter, et que notre code soit adaptable, résistant, et ne casse pas
[00:17:35] à la première pression qui vient, que ce soit une pression qui vient d'un nombre d'utilisateurs, par exemple, ou de quelqu'un qui attaque, qui a créé la solution, une feature qui aurait été juste mal développée, un bug, etc.
[00:17:50] Cette volonté d'antifragilité, on l'obtient après avoir nourri pendant des années et des années une... culture du test. Et quand j'ai commencé à écrire mes premières lignes de code avec cette fameuse machine, vous imaginez bien que les tests, ça n'existait pas. Et pendant très longtemps, j'ai continué malheureusement à apprendre à travailler avec des cycles de vie en V, avec des tests manuels, et ça a duré très très longtemps. En tout cas, pour ma part, je n'ai pas eu de chance d'arriver où le TDD était largement... Implanté et encore l'est-il, largement implanté dans mes expériences récentes. J'ai encore l'impression que 1990, ce n'est pas si loin. Je suis un peu triste, mais voilà. On essaie de remonter, de refaire le parcours de l'évolution. À un moment, il faudrait que l'évolution, elle...
[00:18:42] En histoire quand même, plutôt que de recommencer, recommencer, mais bon, c'est comme ça, création destructrice, on a dit, mais on est censé, à chaque destruction, on est censé quand même monter un palier.
[00:18:53] Et on arrive quand même, aujourd'hui, je pense que, j'espère voir, vous êtes tous habitués,
[00:19:00] à utiliser l'IA et sûrement à faire du code généré par l'IA. Et donc, vous gagnez du temps et vous avez normalement plus de temps pour écrire des tests ou faire faire écrire des tests. Et les agents sont très, très forts pour écrire des tests. Du coup, vous voyez le futur. Sur ce slide, c'est plutôt... Je vais en parler. Plus de tests, aller faire des tests qu'à l'époque, c'était... À l'époque, c'était peut-être il y a 3-4 ans seulement avant, où on se dit, contre le base testing, c'est compliqué, c'est pas pour moi, dans mon projet, Je ne peux pas le faire. Mutation testing, oui, j'en ai entendu parler, mais c'est inapplicable. Tout ça, ce n'est plus vrai.
[00:19:39] Mais je vais y revenir. Vous êtes tous habitués à utiliser l'IA et sûrement à faire du code généré par l'IA. Et donc, vous gagnez du temps et vous avez normalement plus de temps pour écrire des tests ou faire faire écrire des tests. Et les agents sont très, très forts pour écrire des tests. Du coup, vous voyez le futur.
[00:19:15] Sur ce slide, c'est plutôt... Je vais en parler.
[00:19:19] Plus de tests, aller faire des tests comme à l'époque, c'était... Enfin, à l'époque, c'était peut-être il y a 3-4 ans seulement, avant, où on se dit, pour faire du base testing, c'est compliqué, c'est pas pour moi, dans mon projet, je peux pas le faire. Mutation testing, bah oui, j'en ai entendu parler, mais c'est inapplicable. Tout ça, ça n'est plus vrai.
[00:19:38] Mais je vais y revenir. L'architecture aussi sert à créer, à répondre à ce besoin de solidité et du coup à créer de la confiance parce que quand la confiance dans le vide, quand moi je code et que derrière, quand je vais livrer, je peux tomber sur des problèmes d'intégration, des problèmes de perf,
[00:19:58] des issues à cause des failles de sécurité potentielles dans mon code ou dans le code des autres que j'utilise, forcément, c'est un problème et c'est, on va revenir sur une histoire de dette,
[00:20:12] de dette qui existe ou qu'on crée soi-même, à chaque fois qu'on écrit une ligne de code, on est notre part de dette dedans, en fait, d'être.
[00:20:21] Et l'architecte, moi j'attends de lui que... IMED a pas ne serait-ce qu'à pas continuer à créer de la dette et peut-être en résoudre
[00:20:34] et à faciliter ce niveau de confiance que je devais avoir quand je livre du code ou quand je commit un truc dans une branche qui part dans la branche, ce serait mieux qui part en preuve, c'est mieux si on fait du train base
[00:20:50] Donc on peut attendre ce rôle d'architecte qui mettra en confiance ses équipes par un certain nombre de choses. Et on en revient à des principes d'architecture. Il y a des architectes qui disent« je vais faire une architecture». Et qui ont lu le bouquin d'Uncle Bob qui est limité pour une« screaming architecture». Un truc qui crie à la face des développeurs« tu dois faire comme ça, tu n'as pas respecté tel pattern et que ça bloque tout».
[00:21:20] Il y a encore des gens qui y croient beaucoup, fortement, qui ont vraiment créé des designs logiciels basés là-dessus, au risque que ça devienne vraiment lourd. Et de toute façon, et pour l'avoir...
[00:21:33] Je ne pense pas... En tout cas, j'ai vu ces architectures en place et j'ai vu surtout des développeurs qui passaient leur temps à contourner
[00:21:41] Évidemment, ceux-là où on avait voulu les guider. Du coup, on peut se dire que peut-être une architecture pensée de manière un peu plus légère, un peu moins contraignante pour les devs, ça pourrait également fonctionner. A essayer. Il y en a qui ont déjà essayé. Donc les gens, les gens qui construisent.
[00:22:02] Les techs, et leur expérience en tant que techs, ou la DevEx, la développeur expérience. Les architectes devraient s'en soucier. Ils s'en soucient un peu quand ils sont délégués au recrutement, ils s'occupent bien, ils se mettent un peu dans la position des gens qui arrivent sur... Leur truc, leur gros machin dont beaucoup d'architectes sont persuadés que c'est génial et c'était la meilleure chose qui pouvait arriver, mais bon, c'est toujours une question au point de vue. Et aller chercher toutes les petites cartes, tous les éléments de la Developer Experience, ça peut remettre en question pas mal le boulot de l'architecte. Est-ce qu'on a bien pensé? Les histoires de documentation, est-ce que les intentions sont claires, est-ce qu'une personne peut emborder en se sentant à peu près à l'aise sur la base du code, etc. Donc il y a des métriques pour ça. Je vais développer quelques-unes. Chez Google, ils ont un Google Developer Program.
[00:23:14] DX propose un framework dédié à ça.
[00:23:21] Donc il y a des indicateurs d'Evex qui sont apparus et qui, par exemple, à ce qui a été dit à la keynote de ce matin, les métriques d'Europe peuvent trouver leur place de manière peut-être plus intéressante en tant qu'indicateur de ce que le développeur ressent plutôt que comme un objectif à atteindre, mais plutôt pour mesurer si les gens sont à l'aise, si les Técosses sont à l'aise avec leur travail et avec leur... Avec ce qui a été construit par leur architecte. Donc on peut réutiliser les métriques d'oura et les métriques space aussi pour en faire des indicateurs du ressenti, de l'expérience utilisateur. Donc ça, ça va être, c'est des chiffres, donc c'est du quantitatif. Alors, on peut transformer un time to first deploy, donc
[00:24:15] un développeur qui on-board, quelqu'un de l'équipe tech qui on-board, et sa contribution, sa première contribution, à partir de quand elle sera déployée? Si il met six mois, parce que son travail se retrouve dans les pipelines, peut-être qu'il y a un truc qui ne s'est pas bien passé. On peut en faire des indicateurs de qualité. Les slides, il y a tous les liens mis à votre disposition.
[00:24:41] Et aussi, on peut y aller d'indicateurs qualitatifs. On peut faire des... Et ce serait bien, et ça, malheureusement, je n'en ai pas vu beaucoup, faire des questionnaires, des petits sondages pour prendre le pouls un peu des... sur des facteurs qui, des fois, vont être subjectifs. Mais au moins, par exemple, est-ce qu'en tant que membre de la tech, je me sens que mes décisions ou mon travail a de l'impact sur au moins quelque chose? Est-ce que je suis juste un simple exécutant et après, charge au décideur d'utiliser ces résultats ou pas?
[00:25:17] Nous, côté développeur, tout ça nous demande quand même pas mal d'efforts, côté tech, nous demande pas mal d'efforts, pas mal d'efforts qui mettent en contribution notre cerveau, les sollicitations cognitives.
[00:25:34] La mémoire technique, c'est notre savoir-faire technique, tout ce qu'on a appris et tout ce qu'on est encore en train d'apprendre et les choses qu'on a oubliées aussi.
[00:25:45] On nous demande aussi, même si c'est moins flagrant, d'avoir une mémoire au-delà de la technique,
[00:25:56] de ce qu'on retrouve dans le code, mais qui est bien plus que l'application de patterns ou certaines syntaxes ou certains styles de programmation. Peu importe le langage et peu importe le style, une mémoire cognitive qui va, si elle est défectueuse, poser problème quand des choses sont amenées à changer, ou du refactoring ou des évolutions fonctionnelles, et cette déficience de mémoire va impliquer de la résistance au changement, Ou montrer que l'équipe a des points bloquants, qu'il y a des personnes qui ont capturé une certaine connaissance et qui ne l'ont pas diffusée. Et du coup, des choses qui vont être très difficiles à changer.
[00:26:41] On voit aussi des phénomènes de stress et de burn-out parce que soit on est en charge de trop de choses dans le code ou dans les parties techniques, ça repose trop sur les épaules d'une personne qui n'a pas forcément ceux qui le souhaitent, ceux qui le subissent.
[00:26:59] Ça se retrouve aussi, l'onboarding, c'est quand même un bon... Tout ce qui se joue dans les onboardings, il y a un ensemble de métriques à aller creuser derrière.
[00:27:08] Et aussi, les développeurs, à un moment, ont accès à une mémoire du contexte stratégique quand on leur donne ces informations-là. Quand on leur donne, parce que quand on ne leur donne pas tout ça, quand ça manque, ça crée de la dette. Et il y a trois types de dettes, en fait. Tout le monde est à peu près au courant sur la dette technique, mais peut-être moins sur la dette cognitive, et encore moins sur la dette du contexte, qui, dans l'ampleur et l'impact, est en train de grossir, pas ce qu'on fait du code, augmenter, créer, ou augmenter ou créer de toute part par les agents.
[00:27:51] Du coup, l'architecte, il doit venir pour limiter la dette, les dettes, et déjà prendre connaissance que ces dettes existent. Et cette fameuse dette de l'intention,
[00:28:08] Et l'intention, c'est ce qui se passe beaucoup côté produit management. C'est pourquoi, quels sont les vrais besoins, quels sont les objectifs métiers, la culture même du client que l'on sert à travers un produit ou une solution logicielle,
[00:28:25] qui peut devenir une problématique sous vraie limite. Est-ce qu'on veut même confier, c'est une discussion assez récente, ces éléments-là, est-ce qu'on va les confier à des agents? Enfin, on les confie à des agents, mais est-ce qu'on veut que ça sorte vraiment de l'entreprise? En tout cas, si on ne l'a pas, il faut le capturer. Il faut que ça fasse partie du contexte. Et après, par contre, il faut éviter que ça fuit un peu trop.
[00:28:55] Donc, nous voilà, développeurs et architectes, en train de gérer, non pas une dette technique, mais des dettes. Ceci n'est pas une dette, c'est une date. Vous n'avez pas d'image pour la dette.
[00:29:12] Si tu peux refaire rien. Remédier à la dette, donc il y a ce papier qui est sorti, j'ai réadapté mes slides quand j'ai lu ce papier-là, c'est assez intéressant, donc c'est cette personne, Margaret, Margaret?
[00:29:29] Qui met en évidence cette notion de dette collective et de dette du contexte, les artefacts, on les appelle les artefacts de l'intention, puisqu'on développe plus vite
[00:29:42] et on développe mieux aussi, on a remarqué, je pense tous, que les agents codent mieux si on passe par les spécifications d'abord.
[00:29:53] Je pense qu'on a fait... Qui en a fait l'expérience de faire du spec? C'est dans le slide d'après. Commencer par les specs, voir faire rédiger les specs par l'IA, puis faire son code.
[00:30:06] Oui, un peu. Et pour ceux qui ne l'ont pas fait, essayez. Il y a plein de recettes. Je ne dis pas qu'il faut utiliser... J'ai essayé SpecKit. C'était très déçu. C'est très verbeux. Ça bouffe du token. Il y a d'autres façons de faire un peu plus maison qui fonctionnent très bien, comme par exemple... privilégier les specs exécutables, créer un propre DSL interne, un Domain Specific Language. Zia sait très bien faire du behavior-driven development, mais je trouve que le tandem Cucumber-Gherkin est un peu lourdingue. Il a toujours été lourdingue et il est toujours aussi lourdingue, même quand on le passe à la moulinette Zia. Donc, ma préférence pour le DSL, mais ce sera un autre sujet. En tout cas, ça va rester, ce sont des artefacts qui vont rester. Et du coup, éviter de perdre ce contexte. Sauf que ce contexte, il faut l'entretenir. Ce contexte métier, il faut l'entretenir.
[00:31:08] Ok.
[00:31:12] Je suis un super leurre.
[00:31:15] Donc voilà visuellement comment on travaille de plus en plus. Donc on a un peu abandonné, en tout cas pour ma part, c'est vrai que les gens qui sont mis à couder avec les agents, On a un peu abandonné le TDD. Déjà, ça ne marche pas. Faire du TDD by the book avec un agent, ça ne fonctionne pas. Parce qu'il n'est pas câblé comme ça. Il va donner en même temps la solution, l'implémentation et le test. Et lui, t'es contre. Vouloir lui refaire faire du TDD comme on faisait, ce n'est pas très intéressant. Par contre, la deuxième partie, c'est... Oui, on a besoin de tests et on a besoin d'encore plus de tests. Donc, les tests sont encore plus là. Ils ne sont pas forcément... Alors, on va générer, justement, on va faire générer plutôt des tests qui vont ressembler plus à de l'acceptance, mais ça peut être des tests d'acceptance unitaire. Ça va être des tests isolés. Je ne parle pas de faire du test end-to-end. Il dit que tout devrait être spécifié, y compris une spécification technique et qu'on devrait pouvoir tracer jusqu'à son origine l'intention et que cette traçabilité, maintenant, elle est dans le code. C'est le markdown. On n'a plus besoin d'aller mettre ça dans des...
[00:32:27] Dans des portails d'informations qui sont déconnectés du code, on peut tout rassembler. Et du coup, les agents vont se nourrir d'un contexte bien plus riche et proposer du code bien plus pertinent, auquel on va rajouter dans notre boucle. Donc, c'est des boucles qui vont très vite. Donc, on est très extrême programming comme on fait ça. On reste dans cette idée.
[00:32:55] De investir dans des choses qui paraissaient un peu hors d'atteinte, comme test automatisé sur la perf, mais aussi des termes d'architecture, par exemple l'automatisé.
[00:33:10] Du coup, on peut faire beaucoup de choses et il faut se maintenir à faire les bonnes choses.
[00:33:20] Les bons choix de design technique, c'est des réflexions et un choix qui est un renoncement à ce qu'on ne va pas garder. Il faut, pour pouvoir faire ça, ça a été un peu mentionné dans la keynote de cet après-midi, il faut faire les choix de manière non plus pas trop précipitée et en ayant bien en tête les impacts de ces choix, sachant que tout ça est un peu imbriqué, que la technique est sous pression de l'architecture, l'architecture est elle-même sous pression des demandes métiers, mais que c'est aussi une surface de friction, si quelque chose se passe mal d'un point de vue purement technique, ça oblige à revoir une architecture, et si on a foiré des choses dans l'architecture,
[00:34:09] ça va frotter avec les gens du métier, on va dire non, on ne sait pas réaliser tout ce que vous nous avez demandé, la manière dont vous nous l'avez demandé.
[00:34:20] Donc on en vient un peu à comment prendre ces décisions techniques, ou d'architecture les deux.
[00:34:28] Il y a un processus, la technique qui s'appelle« advice process», qui nous invite à découper à y aller par étapes dans notre prise de décision. En commençant par cibler un problème, obtenir des informations qui alimentent la réflexion sur le problème, définir des critères de choix avant de choisir, avant de choisir même entre plusieurs solutions, et ça, ça a été abordé tout à l'heure, pas trop de solutions non plus, mais avoir quelque chose d'assez... Alors, peut-être deux choix, je ne sais pas, est-ce trop, pas trop, mais suffisant, je ne sais pas quel est le bon nombre, avoir des matrices d'évaluation sur les bénéfices-risques. Uh, se décider, il faut trouver par quel processus on va décider. Est-ce que c'est par consensus? Est-ce que c'est par vote majoritaire? Est-ce que c'est une personne qui tranche pour tout le monde? Documenter cela. Ces prises de décision, ça commode de formats qui vont bien aujourd'hui et qui sont assez communément admis.
[00:35:42] Les RFC, est-ce que ça parle à des gens, les Requests for Comments? Pas forcément tout le monde. Internet a été bâti, l'Internet que vous utilisez aujourd'hui, a été bâti sur des RFC, donc TCP, IP, SMPP, HTTP, tout ce qui est en partie, tous les protocoles viennent d'un
[00:36:01] long processus d'échange, d'abord, avant d'arriver à la décision. les requests for comment, on me demande, venez commenter ma proposition, qu'est-ce que vous en pensez, c'est bien, c'est pas bien, ça débat, etc. D'où ces états. Et l'ADR est là pour finaliser l'architecture de ce genre, et là, plus lui, pour finaliser ce qui s'est dit lors du NRC. Et ça aussi, c'est du contexte pour les agents, très utile, au moins l'ADR. La RFC, je me verrais plus pour les humains, pour essayer à un moment de faire de l'archéologie, mais pourquoi? Pourquoi on en est arrivé là? Qu'est-ce qui s'est dit? Est-ce qu'on avait les bons critères de décision? Est-ce qu'il y a eu des bonnes discussions? Quitte à les recommencer, mais en tout cas, garder la mémoire de ça, c'est méga important.
[00:36:49] Ce n'est pas du luxe.
[00:36:52] Parce que pour en venir à la prise de décision ensuite, OK, on a les options sur la table, on a les bons critères d'évaluation, il faut trancher. Comment? Brainstorming? On pense tous que c'est bien, mais en fait, j'ai piqué dans une actualité récente, c'est le gars qui fait Foloscopie, si vous ne connaissez pas sa chaîne, c'est vachement bien. Il était à l'université de Grenoble, en plus. On l'avait eu en live, c'était super.
[00:37:22] Et bien, brainstorming, non. C'est un peu lent, ce n'est pas forcément, on a pris une étude, des études scientifiques, par rapport à la recherche en solomène.
[00:37:34] Il y a pire, en termes de prise de décision, ces fameux architectes qui viennent verrouiller les décisions.
[00:37:45] Alors que d'autres modèles de décision émergent, ceux qui incitent à prendre les parties parlementaires et à rassembler un peu tout le monde pour
[00:37:55] déjà discuter, mais de manière ciblée, plutôt orientée selon tel problème. On ne prendra pas les mêmes parties impactées, et du coup, ce ne sera pas non plus les mêmes experts qu'on devrait solliciter. Et il faudrait que celui qui prend la décision ne soit pas toujours la même personne.
[00:38:14] Ça a été mis en évidence et ça fait l'objet d'un bouquin que je trouve assez passionnant. Je suis presque la moitié.
[00:38:25] C'est le bouquin de Andrew Armel Lowe, je prononce bien, qui avait commencé sa réflexion il y a quelques années sur le blog de Martin Fowler. Vous pouvez trouver l'essence du bouquin, le début de sa réflexion en ligne, sur cette adresse-là. Il avait déjà sorti ses réflexions sur l'advice process et l'architectural advice process.
[00:38:53] Où est-ce qu'on fait des RFC, où est-ce qu'on utilise les RFC, les ADR, est-ce qu'on met en place un... Un tech radar, ça c'est largement détaillé dans le bouquin, mais c'est disponible dans ce billet de blog.
[00:39:10] Donc, il invite pour une prise de décision décentralisée qui change en fonction du besoin et du contexte aussi. Donc à chaque fois, ce ne sont pas les mêmes groupes de personnes à chaque décision. On prend des groupes de personnes différents en fonction de ce que la décision implique, pour que ce soit plus rapide. C'est tout dans le bouquin. Et il invite aussi à créer des advice forums, très facile à faire sur un projet GitHub ou GitLab, par exemple, et qui est ces discussions avec des mécanismes de vote, etc. Le plus dur aussi, je pense, le boulot de l'architecte,
[00:39:52] de faire vivre ces discussions-là, parce que les gens, ils ne vont pas forcément tout seuls. Donc, il faut l'alimenter.
[00:39:59] On peut poser un truc et puis ça va rester, il va y avoir trois discussions et puis ça va s'arrêter.
[00:40:05] Et voilà pour le portrait de ce qu'on peut faire là aujourd'hui en tant que dev et architecte. Et demain? Et demain, à quoi ressembleront nos architectes? Est-ce que ça ressemblera à ça? des advice forums, très facile à faire sur un projet GitHub ou GitLab, par exemple, et qu'il y ait ces discussions avec des mécanismes de vote, etc. Le plus dur aussi, je pense que le boulot de l'architecte va être de faire vivre ces discussions-là, parce que les gens, ils ne vont pas forcément tout seuls, donc il faut l'alimenter, pas non plus... On peut poser un truc et puis ça va rester, il va y avoir trois discussions et puis ça va s'arrêter.
[00:40:05] Et voilà pour le portrait de ce qu'on peut faire là aujourd'hui en tant que dev et architecte. Et demain? Et demain, à quoi ressembleront nos architectes? Est-ce que ça ressemblera à ça?
[00:40:26] C'est trop facile, je vais trop vite.
[00:40:29] Pour éviter qu'on arrive à ça, je pense qu'il faut jouer sur une corde très sensible, qui est la différenciation entre le contexte. Les IA, on le sait, sont sensibles au contexte, tandis que nous, humains,
[00:40:45] Nous, on est bien au-delà du contexte. Nous, on vit avec notre culture. Et la culture, c'est quelque chose d'un peu complexe, c'est des échanges entre humains, c'est des échanges avec ce qui a été écrit, il y a à la fois de la matière morte et de la matière vivante, et surtout ça s'est nourri, c'est enrichi, ça passe le temps, ou pas, d'ailleurs les choses se disent, les principes d'architecture logicielle des années 2000 ne sont plus d'actualité aujourd'hui, et peut-être c'est bien, mais peut-être c'est pas bien, je sais pas.
[00:41:20] En tout cas, cette culture, elle nous permet de nous exprimer, même sur des sujets techniques, avec des atouts humains qui peuvent être une vraie créativité et pas juste un délire stochastique. Et aussi, un truc que n'ont pas les agences, c'est qu'on arrive quand même à sentir des choses. Cette intuition, ce truc qu'on ne peut pas mathématiser, qui fait qu'on va prendre telle décision.
[00:41:49] Est-ce cette culture? elle s'entretient, elle existe depuis longtemps, déjà sous une forme littéraire. Donc il y a énormément de littérature sur la programmation, le fait de programmer, d'écrire du code, quel que soit ce code. On le trouve aussi sous des formes, maintenant, de pas mal de chaînes YouTube, d'ici, dédiées. Et aussi, ça diffuse dans la culture générale, à tel point qu'on trouve des podcasts sur des radios nationales, des radios généralistes. De qualité, évidemment.
[00:42:23] Et si vous ne connaissez pas le podcast Le Code a changé sur Radio France, je vous invite vraiment à aller écouter, c'est super intéressant. Même pour les développeurs, écoutez comment on vulgarise, on va apprendre énormément de choses. Et d'ailleurs, il y a un épisode du podcast, je pense qu'il date d'il y a deux ans, sur l'architecture, l'architecte civil, comment l'architecture civile a été influencée par le logiciel. Et comme l'architecture civile, c'est quand même, on vit dedans, et ça modélise nos cités, comment des éditeurs de logiciels tels que Autodesk, Ademi, influencent sur l'organisation des gens dans les îles. C'est assez dingue, il faut l'écouter. Et il y a aussi, je suis tombé sur cette initiative, Thomas Petrisek, qui fait une exposition sur la culture de la programmation. Donc, je clique un peu. C'est une exposition qui s'annonce être itinérante. J'espère qu'elle viendra à Paris et pourquoi pas, elle pourrait être... sa place à Flocon. Il a parlé des cultures, et là, la culture mathématique, la programmation logicielle est née des maths, les premiers penseurs, les premiers programmes sont quand même essentiellement mathématiques. Puis, par-dessus cela, c'est greffer la culture des hackers, c'est greffer la culture des ingénieurs, les gens sérieux. Et des gens super encore plus sérieux qui veulent faire de l'argent et du management avec le boulot des gens du dessus.
[00:43:51] Il ne faut pas oublier que cette culture est avant tout humaine, une culture humaine, avec des travers que seuls les humains peuvent avoir. Et il met en exergue un travers que j'ai appris un truc, Alors, HyperCard, c'est très vieux, c'était pour les premiers Apple, Apple II, Apple I, et les tout premiers Macintosh. On appelait ça Macintosh. C'est un espèce d'ancêtre d'Excel que le mec a codé sous un trip au LSD, quand même. Je ne savais pas, mais je veux bien le croire, et ça me fait beaucoup rigoler. Là, c'est de la sous-culture, pour beaucoup.
[00:44:24] Du coup, nous, architectes avec une culture,
[00:44:31] et une culture faite de techniques et d'échanges entre les personnes, donc social-technique ou technico-social, on en a déjà parlé tout au long de la journée,
[00:44:45] Et je me suis dit, attends, la culture dans le futur, ça pourrait être quoi? Il se trouve que j'aime bien la science-fiction et j'ai commencé à lire un peu tard quelques space opéras, dont un particulier qui s'appelle« Le cycle de la culture». Ça a frappé mon esprit. Et dans le cycle de la culture, cet auteur, il y a une banque qui connaît.
[00:45:10] Je n'ai pas lu en entier, parce que c'est du space opéra, c'est fleuve. Mais la culture est une nouvelle civilisation qui ne domine pas l'univers, mais qui a quand même une place importante, qui est très sage, qui est une espèce de... Il y a des IA dedans, il y a des néo-humains, des post-humains. Elle a une sagesse infinie, elle a aussi beaucoup d'humour. Et donc, j'ai demandé à une IA d'aujourd'hui de, si on mixait les architectes, mon histoire de culture d'architecture avec la culture de Youngbanks, les livres de Youngbanks, voilà ce qu'il m'a dit, on pourrait imaginer effectivement les architectes de la culture, ces espèces. d'être un peu super savant, qui voit le monde. Mais les architectes de la culture, de la science-fiction, ils ont certaines caractéristiques, ils ont certaines caractéristiques. Donc ils sont contre la hiérarchisation. Ils sont post-humains, ça me pourrait dire.
[00:46:14] Ils ont du pouvoir, mais ils n'aiment pas trop le montrer.
[00:46:18] Ils savent intervenir, ils sauraient intervenir au bon moment. Par contre, quand la culture intervient, il ne vaut mieux pas trop être dans le champ de bataille parce qu'elle n'est pas belliqueuse, mais la culture n'est pas une contradiction très...
[00:46:36] La culture construit des grands projets, c'est une méga civilisation qui est basée sur la permanence et la durabilité.
[00:46:49] Du coup, nos architectes logiciels pourraient s'inspirer de cet aspect-là de la culture. Alors, ça c'est généré par un délire, par une fusion des gens. La dernière ligne, j'ai dû la changer parce qu'il m'a dit« qui évite de conduire un autre humain au suicide dans 5 ans? » J'ai« oups! » Ça, c'est pas politiquement correct, mais parce que c'est un peu violent dans les livres. Du coup, le mix, il a un peu dérapé. Ah, mais c'était rigolo.
[00:47:22] C'est des délires de l'IA, mais j'ai trouvé ça radicalement pacifiste avec les codeurs. Imprétable avec la dette, l'ennemi c'est la dette, l'ennemi c'est pas le développeur, mais c'est peut-être des... On voit ça dans certaines boîtes, malheureusement, on se demande qui est l'ennemi, si c'est les gens qui bossent ou si c'est les vrais défauts dans ce produit. Du coup, grâce à la philosophie de la culture, donc la culture grand T, le grand C, on pourrait voir les choses différemment, notamment arrêter de blâmer les développeurs, de ne pas être des policiers du code, c'est quelque chose de difficile. À s'y tenir.
[00:47:59] On a dit compétent, mais qui sait se mettre en retrait. On retrouve ça dans des initiatives, ça a quelques années. J'aimais bien l'initiative d'April Denzel sur le compassionate coding. Je code pour les autres, je ne code pas pour moi.
[00:48:13] Et on est quasi à la fin. Pas de process lourds, pas d'architecture qui crie sur les gens, des process légers.
[00:48:24] Éliminer les rituels inutiles et accepter quand même des erreurs, mais avec des choses qui permettent de voir les erreurs plus rapidement et ensuite de les rattraper.
[00:48:40] le côté pragmatique soit bien avec. Et je vais finir sur la note inattendue. Dans la culture, la société de la culture a beaucoup d'humour, d'autodérision sur elle-même. Et parce que les gens, Yann Bans estime que les gens brillants sont avant tout des gens qui ne se prennent pas trop au sérieux, qui sont fun, qui mettent du fun dans ce qu'ils font. Il y a des trucs super fun que fait la culture.
[00:49:05] Pour tout un tas de bénéfices. Par exemple, si vous voulez être façon la culture, vous pourriez nommer du matériel interne, j'allais dire, des choses que les utilisateurs ne vont pas voir, des noms de classes, des noms de packages, des noms de serveurs, ce que vous voulez. Façon, ce qu'on trouve dans les bouquins du site de la culture.
[00:49:31] Et c'est assez marrant. Écoute, j'ai raison. Ça ne te regarde pas. C'est moi le médiateur.
[00:49:38] Et là, on comprend assez bien.
[00:49:42] Encore du délire d'IA, je vous trouve ça super marrant. Donc voilà, on fait ce qu'on veut. Je vous remercie, c'était la petite conclusion.

Transcription