Transcription

• Speaker #0

  Il y en a combien qui sont venus nous voir en nous disant j'ai vibecodé un truc, ça ne tient pas la charge, ça marchait bien pour relever les fonds, mais maintenant on a plein d'utilisateurs et ils ne sont pas contents. On fait dix fois plus d'applications, mais on a dix fois plus de problèmes.

• Speaker #1

  Avec l'IA, le coût d'écriture du code s'effondre. Donc des applications métiers qui ne passaient jamais le seuil de rentabilité vont voir le jour. Et beaucoup s'en attient, ni c'est standard. Après, dans notre entreprise, qui va les tenir ? J'ai posé la question à quatre personnes qui font du logiciel. Pendant le Comit, une conférence tech qu'Axabreta organise à Aix-en-Provence. Constantin Guay est CPO de Transition, François Nicolenco est CPO chez IETA, Manon Bertellimi est CTPO de Charlie et cofondatrice de DevMachine, et Hubert Grégoire est CTO d'Exabrica. On verra pourquoi Hubert compare nos applications aux serveurs avant les solutions cloud, et ce qu'une DSI peut faire de pire selon Constantin. Puis François emprunte une idée au design pour que des centaines d'applications tiennent ensemble. Et Manon nous dit combien de temps il nous reste pour tout mettre en place. A la fin, vous repartirez avec... quatre regards de fous et aucun ne passe par un outil magique. Et comme d'habitude, nous avons fait un guide résumé de cet épisode. Le lien est en description. Constantin, raconte-nous la fois où tu as vu une application, on t'a récupéré ou tu as vu passer une application qui a été largement générée avec l'IA, peut-être par des gens du métier ou autre. Dis-moi, qu'est-ce qui fonctionnait, qu'est-ce qui marchait, qu'est-ce qui tenait, mais surtout là où ça pouvait ne plus tenir. Et pourquoi à un moment donné, l'IT devait intervenir ?

• Speaker #2

  Alors, j'ai plusieurs cas. Le premier, c'est moi. C'est moi aussi qui, pour mes besoins d'accompagnement de l'équipe, j'ai dû faire une surcouche d'applications. Ce qui était assez intéressant d'ailleurs, parce que ça permettait de pouvoir se mettre dans un mode où je ne touchais pas aux trucs qui sont dangereux pour l'IT. C'est-à-dire que c'était une surcouche, c'était vraiment plus une interface. pour améliorer l'interface d'utilisation d'un outil, d'un board en fait, tout simplement. Donc ça, c'est le premier cas vraiment que j'ai vu. D'autres cas, c'est le métier justement qui se mettait vraiment en posture de se dire en fait, j'ai des besoins, je suis frustré parce que les équipes ne peuvent pas suivre. Et donc justement, ils ont vu ce déclenchement qui leur a permis justement de se dire en fait, je vais le faire moi-même. Et là où c'était intéressant, c'est qu'effectivement, ce n'était pas utilisable en soi, mais que ça nous a permis de lever des alertes et de nous demander justement comment est-ce qu'on peut faire pour leur laisser quand même cette capacité, parce qu'on a vu l'avantage que ça pouvait donner, mais dans un environnement sécurisé pour l'entreprise.

• Speaker #1

  Et François, toi, tu as vu la même chose ? Tu as des cas similaires ? Oui, des cas similaires.

• Speaker #3

  Ce que je remarque beaucoup, c'est que maintenant que les outils et les monnaies sont disponibles partout, tout le monde test en silo. Du coup, beaucoup d'équipes vont générer pas mal d'applications. Rapidement, il y a cette problématique de centralisation et de méthodologie commune, où les gens sont partis tellement dans des directions différentes que ça devient presque impossible de rattraper. Des cas aussi où, c'est vrai qu'on en parlait juste avant, mais c'est par exemple des CEOs ou des personnes qui veulent tester eux-mêmes. et développer, générer des prototypes, des choses pour se projeter. Effectivement, quand on récupère ça, la matière, bien qu'elle existe, elle est très peu exploitable sur tous les paramètres, aussi bien sur l'UX, sur le design que sur les mécaniques derrière de logique. Pourtant, ils peuvent être très convaincus que c'est une bonne solution. Donc, il y a quand même tout un plan de métier à prendre en compte, de mécanique produit. à prendre en compte avant de laisser de la place et de libérer tout le monde avec ces outils-là.

• Speaker #1

  J'aimerais bien qu'on fasse un petit tour pour avoir votre avis sur, quand on augmente justement ce flux de création d'applications, à votre avis dans le futur, quand on aura 10 fois plus d'applications, 20 fois plus, 50, 100 fois plus d'applications, c'est quoi le premier goulot, le premier étage qui va tomber ? Est-ce que c'est... Est-ce que c'est le socle technique qui ne va pas suivre ? Est-ce que c'est le flux de décision qui ne va pas suivre ? Est-ce que c'est l'intention ? Est-ce que c'est le test ? Est-ce que c'est l'équipe, l'organisation d'équipe ? Manon, je veux bien avoir ton avis, après Hubert, puis après Constance 1 et François, s'il te plaît.

• Speaker #4

  Un peu tout, dans les exemples que tu as donnés. Je pense qu'aujourd'hui, ça va très vite. Le premier, c'est que si on produit plus de codes, il faut aussi les relire. On peut automatiser la relecture avec d'autres réacteurs, mais c'est quand même bien d'avoir des relectures de développeurs. Une fois qu'on a géré ça, ça va être sur l'idéation, sur la profondeur des spécifications, la profondeur du besoin. C'est-à-dire que maintenant, on peut aller plus vite aussi d'idée à la réalisation. L'idée c'est bien, mais il faut aussi bien la creuser, savoir ce qu'on veut mesurer derrière sur les utilisateurs finaux. Je pense qu'en fonction des équipes, en fonction des contextes, toute la chaîne est bouleversée. Et donc on améliore en fonction des goulots d'étranglement qu'on voit et qu'on améliore à cet endroit-là. Mais assez rapidement, c'est un autre endroit que le... D'autres problèmes, où c'est plus lent, soit plus lent ou soit moins bien fait. On parle aussi de méthodologie et d'aligner tout le monde sur la méthodologie, c'est important.

• Speaker #1

  Hubert, pour toi, celui qui lâche en premier ?

• Speaker #0

  Je ne sais pas, je pense qu'avec beaucoup d'applications faites à l'initiative des métiers dans les entreprises, on risque d'avoir des doublons aussi. C'est le chef X qui a décidé que c'était lui qui faisait son appli ou en tout cas son équipe et on retrouve le chef Y qui fait la même chose. Il va falloir arbitrer donc des problèmes de gouvernance. Les mêmes problèmes aussi que les scale-up rencontres après avoir été startup où il y en a combien qui sont venus nous voir en nous disant j'ai vibecodé un truc, ça ne tient pas la charge, ça marchait bien pour relever les fonds mais maintenant on a plein d'utilisateurs et ils ne sont pas contents. Donc en fait c'est... comme disait Manon, la même chose qu'aujourd'hui, mais en accéléré. On fait dix fois plus d'applications, mais on a dix fois plus de problèmes. Donc il va falloir réguler tout ça.

• Speaker #1

  Génial. François, Constantin ?

• Speaker #3

  Effectivement, je suis aligné là-dessus, et je pense que, rapidement, ça va quand même remonter dans la chaîne au niveau décisionnaire. C'est là où on va avoir le plus de problématiques, parce que comme... Les outils maintenant, il y a cette accessibilité, tout le monde les utilise, il y a cette facilité d'accès. La priorisation, le choix, le pourquoi et la valeur va remonter à cet endroit-là. Et il va y avoir des goulots parce que beaucoup plus de personnes auront du temps pour vouloir décider et auront envie de se positionner sur des choix auxquels ils ne pouvaient pas participer avant. Et c'est là où il va y avoir pas mal de travail à faire pour pouvoir aligner tout ça. et créer des méthodologies pour le faire.

• Speaker #2

  Je ne vais pas redire les mêmes choses, mais je pense que d'un point de vue vraiment très pratique, les gens qui vont en pâtir le plus, c'est les psychops qui vont devoir gérer ça. Mais aussi, on parlait de chaîne de décision, le décisionnaire sur une start-up, ça peut être le CEO ou des directeurs de département qui vont devoir aussi arbitrer justement. Est-ce que ce qu'on a fait là, ce que tu as fait là, ça va dans le sens de l'entreprise, dans le sens du business ? Et donc ça va aussi nécessiter justement que ces gens-là transmettent mieux l'information de ce qui est important pour le business aujourd'hui. Qu'est-ce que c'est la valeur de notre business ? Et du coup, pour soit décider, soit donner les clés aux gens qui font ces apps, pour décider si c'est vraiment la bonne chose.

• Speaker #1

  Ces apps qui vont être construites, elles vont vivre ? vieillir, pas forcément être touché. Pendant ce temps-là, les systèmes évoluent, les harnais évoluent, les modèles évoluent. Qu'est-ce qu'on fait de ces applications ? Est-ce qu'on les régénère from scratch ? Ou on les fait maintenir par l'IA ? Ou les applications qui peuvent devenir obsolètes, ou en doublons, est-ce qu'on arrive à les décommissionner facilement ? Je veux bien ton avis, Manon, déjà, au début, et Hubert aussi.

• Speaker #4

  Alors, tu as posé plein de questions.

• Speaker #1

  Désolé.

• Speaker #4

  Moi, je n'ai pas encore vécu d'écomissionnement d'application. On voit qu'il y en a plus, etc. La data, en fait. Je pense que la base de tout ça, c'est l'applicatif, on peut le régénérer. Ça va prendre quand même du temps, ce n'est pas fait en un claquement de doigts. Mais les spécifications, on peut aussi les régénérer à partir du code. Est-ce que ça vaut le coup de maintenir des spécifications ? Il y a plein de questions qui se posent. Mais pour moi, la clé de tout ça, c'est la data. Qu'est-ce qu'on fait de la data de toutes ces applications ? Comment on monite tout ça ? Comment on gère le surplus d'applications ? pour que le livrable à la fin soit correct.

• Speaker #0

  Beaucoup de changements vont arriver. Je pense qu'on vit un peu la même chose avec les applications qu'on a vécues à l'arrivée du cloud avec les serveurs. Avant le cloud, un serveur, on le bichonnait, il fallait maintenir son espace disque, sa mémoire, etc. C'était le pet, l'animal de compagnie. Et avec le cloud, on parle plutôt de cattle, plutôt de batteries d'animaux qui ont des numéros et qu'on peut créer ou détruire facilement. Pour les applications, on n'en est pas encore là, mais je pense qu'on peut arriver vers ça. Et je pense qu'on va régénérer les applis quand on en aura besoin. Effectivement, il faudra conserver les datas, il faudra faire évoluer les specs et peut-être enlever des choses. Parce qu'on a vu que dans les usages, il y a des fonctionnalités qui ne sont pas utilisées. Et on pourrait avoir quelque chose de beaucoup plus frugal qu'une somme d'applications qui sont sous-utilisées. Donc c'est un rêve, je me projette à long terme.

• Speaker #1

  Merci Hubert. Moi je me pose une question sur ces métiers qui vont pouvoir générer toutes ces applications, ou ces PM ou d'autres personnes dans différents services. Qui va faire les arbitrages de qu'est-ce qu'on a le droit de construire et qu'est-ce qu'on n'a pas le droit de construire en fait ? Et qui va prendre la responsabilité ? Et surtout, qui a la responsabilité le jour où l'application qui est utilisée par le service va s'effondre et empêche le service de bien travailler ? Donc voilà, François, tu veux démarrer ?

• Speaker #3

  Là-dessus, je pense que le marché au global, il va un peu réguler ça en fonction des besoins. et je le vois toujours comme une chaîne descendante, c'est-à-dire que ça va envoyer un certain nombre de signals, un certain nombre de datas, d'indicateurs qui vont valider ou invalider l'utilisation de telle ou telle application dans les équipes métiers. Et surtout, même si on pense un peu plus large, directement pour les utilisateurs, effectivement, on va pouvoir détruire beaucoup plus facilement et donc tout ce qui n'aura pas de sens ou qui n'apportera pas de réelle valeur va être beaucoup plus rapidement aussi éliminé.

• Speaker #1

  Constantin, tu veux rebondir ?

• Speaker #2

  Oui, je pense qu'il y a une notion qui va changer aujourd'hui. On voit le logiciel comme quelque chose de pérenne. Je pense qu'effectivement, ce qu'on va devoir apprendre à changer dans notre conception du logiciel, c'est le logiciel jetable. J'avais un exemple que j'avais montré dans une précédente conférence sur le jeu vidéo. Aujourd'hui, on achète un jeu vidéo, on joue à notre jeu vidéo, ou on n'y joue pas d'ailleurs. Beaucoup de gens sur Steam n'ont jamais joué à la majorité de leur librairie. La fameuse bibliothèque Steam, plein de jeux qu'on n'a jamais joué. Mais en fait, moi j'avais fait des tests, donc c'était en plus sa date, c'était il y a un an maintenant. J'avais fait des tests où je demandais juste un prompt à Claude, très rapide, en lui disant ce que j'aime sur un jeu, etc. Et en live, pendant que je parlais, en moins de deux minutes, il m'a fait un premier niveau d'un jeu complètement comme ça, qui était fait que pour moi, sur lequel je pouvais jouer. il aurait pu aller plus loin, le faire qu'il apprend comment je joue ce premier niveau pour me générer le deuxième en fonction de ça et tout. Donc c'est quelque chose qui au final, une fois que j'ai joué une fois, potentiellement je vais le jeter. Donc il y a vraiment cette notion à mon avis qui va arriver de logiciel tellement facile à faire qu'on va pouvoir le jeter facilement. Et même dans le monde de l'entreprise, on va faire un logiciel pour un projet et on va le jeter ensuite parce qu'il n'aura plus de sens. Et là effectivement où je vous rejoins, c'est le côté de... Comment est-ce qu'on orchestre ça ? Il y a deux niveaux à mon avis. Il y a le niveau décisionnaire, le CEO, comme je disais tout à l'heure, qui doit savoir donner un cap. On espère qu'il le fasse déjà aujourd'hui, ce n'est pas souvent. Mais en tout cas, il doit apprendre encore plus, pour encore plus de raisons, à donner un cap pour savoir ce qui est important. Mais aussi tous les métiers autour de l'IT aujourd'hui, qui doivent fournir des outils sécurisés, qui doivent fournir des moyens de le faire. parce que je pense que la... La moins bonne chose à faire, la pire des choses à faire serait de brider. justement ce besoin et cette envie que vont avoir les équipes de faire quelque chose. Donc si on ne leur met pas les outils, ils le feront comme ils font déjà, ce qu'on appelle le shadow IT, ça se passe déjà. Donc là, ce sera encore plus amplifié, encore plus dangereux. Donc je pense vraiment qu'il y a un gros, gros intérêt pour les entreprises à cadrer ça, à faire des repositories de skills, à faire que chaque département qui a chaque spécialité alimente justement une sorte de cerveau central. qui va pouvoir justement faire les choses bien pour que n'importe qui puisse faire son logiciel en toute sécurité.

• Speaker #3

  Là-dessus, ce que je pense aussi est intéressant, c'est de voir cette notion de culture. Du coup, il y a une évolution de la culture tech et de la culture produit. Et là-dedans, je vois beaucoup la culture produit qui fait un shift et qui va aller beaucoup plus sur cette culture à impact. Et donc, il va y avoir un peu cette notion de OKR, mais avec un héros. d'avoir un découpage, mais qui est vraiment beaucoup plus précis et qui permet de faire des bundles pour laisser de la liberté, pour l'innovation, et qui va influer cette vision qui va venir de la direction du COMEX. Et je pense qu'il y a vraiment cette notion-là aussi qui va devenir encore plus importante au vu des divergences possibles.

• Speaker #2

  Et ce que tu dis est super intéressant, parce qu'effectivement, il y a ce côté d'impact. Et aujourd'hui, les gens se satisfont, dans les grosses entreprises, souvent de ne pas avoir d'impact. Je fais mon boulot. En vrai, si j'ai un impact ou pas, je ne regarde même pas. On ne me le dit pas de toute façon, donc ça passe et puis je continue. À partir du moment où justement les gens vont beaucoup plus s'impliquer dans la création de leurs propres outils, l'impact va être beaucoup plus important à être recherché. Et encore une fois, comme je disais tout à l'heure, ça risque d'être encore plus frustrant. Et je pense que des gens de qualité qui veulent avoir un impact, il faut savoir les garder. Et que si on ne leur donne pas les outils pour l'avoir, ils vont aller voir ailleurs tout simplement.

• Speaker #1

  Donc on a ces personnes métiers qui vont construire des applications, avec peut-être, elles vont essayer de construire une application plutôt solide, qui fonctionne bien à leur niveau. Elles vont vouloir qu'elles soient en prod, ces applications, sur un vrai environnement d'entreprise, sur lequel toute entreprise peut l'utiliser. Uber, qu'est-ce que... Qu'est-ce qui... doit être vérifié ? Qu'est-ce qui doit être vrai pour l'application ?

• Speaker #0

  Vaste question.

• Speaker #1

  Qu'est-ce qui doit être, surtout, c'est quoi la vérification systémique, systématique qu'on doit avoir pour accepter ces applications-là ?

• Speaker #0

  On a parlé d'Arne dans la journée, on a parlé de Guardway. Les agents vont générer du code, on sait qu'on en a parlé. Il y a des hallucinations, il y a des problèmes, mais Merci. Tout ce qui est agentique, c'est des collaborateurs comme les autres. Il va falloir qu'ils passent dans les chaînes de tests qu'il faudra faire encore plus qu'avant, où l'humain de lui-même pouvait faire des autocontrôles. L'agent, lui, ne s'autocontrôle pas. Donc, on ne parle pas de tests unitaires, on parle de tests fonctionnels, etc. Il faudra encore mieux définir les specs, le besoin. On a parlé de définir des ontologies, définir le besoin de façon beaucoup plus détaillée. Donc si on arrive à bien définir les fonctions de façon lisible par une machine, on pourra facilement générer des tests qui seront faits par une machine et qui vont contrôler le code fait par une machine. Donc en fait, pour répondre à la question, il faut que toute la chaîne de build et même au-delà, tout le SDLC du... du développement logiciel soit partiellement automatisé, toujours avec un peu de human in the loop au milieu pour surveiller tout ça et que ça parte pas en sucette. La partie DevSecOps, effectivement, la partie sécurité aussi, parce qu'il y a des abus. Et en fait, rien ne change, sauf qu'il faut être un peu plus exigeant, ou beaucoup plus exigeant sur les pratiques qui sont pénibles, longues à mettre en œuvre quand c'est des humains, mais les agents, on peut se permettre de les appliquer à tous les étages.

• Speaker #1

  Tu veux rajouter quelque chose, Manon ?

• Speaker #4

  Non, c'est assez complet. C'est toute notre chaîne, au final, qu'on sécurise. Avant, quand on était sur une user story, c'est-à-dire qu'elle avait été maturée avant, quand elle était prête à être envoyée en développement, c'était que normalement il y avait une réfection. Vu que maintenant, on va encore plus vite, il faut bien la sécuriser sur toute la chaîne, c'est toute l'usine logicielle. Sur l'impact, avant de bien vérifier que l'impact recherché est bien présent, ou sera bien présent.

• Speaker #1

  Là, on parle beaucoup d'une application qui a été produite et qu'on essaye de tenir. Qu'est-ce qui se passe quand demain il y en aura 100, 200, 300 applications comme ça, qui vont vivre, qui vont vieillir tout en même temps peut-être, ou toutes avoir les mêmes petits problèmes dans la chaîne et qu'il va falloir gérer ça ? François, ton avis, qu'est-ce qu'on peut faire ? qu'est-ce qu'on peut amener comme cohérence ?

• Speaker #3

  Là-dessus, j'ai un peu une conviction, c'est de réfléchir dans un modèle atomique, un peu comme on peut penser à un design system ou ce type de structure, et donc de vraiment commencer par créer un cœur, une mécanique, un langage commun, avec une architecture commune, et ensuite de pouvoir le déployer avec un ensemble de composants, du coup de ces composants, d'aller dans la granularité à tous les niveaux. Et ce qui est intéressant, c'est de le penser maintenant avec ces nouveaux outils, pas dans les aspects visuels, mais au global. Donc on peut aller très très loin dans la complexité et combiner ces éléments pour qu'ils puissent fonctionner ensemble dans cette matrice. Ça permettra d'avoir un lien et de garder une cohérence sur tout ce qui va être fait puisqu'ils sortent tous, entre guillemets, du même moule, de la même... de la même première vision. Et vraiment sur l'aspect purement interface, effectivement, je pense qu'il y a un grand rôle sur ce côté DS, parce que la manière dont il est structuré et sa capacité à être maintenant lu par tous les modèles va permettre de générer de manière consistante et cohérente quasiment tout ce qu'on veut. Et donc, les groupes ou les organisations qui auront mis un peu d'énergie, voire beaucoup d'énergie là-dessus, vont se retrouver avec une facilité de déploiement et de scalabilité pour l'ensemble de l'organisation qui va être hyper puissante, je pense.

• Speaker #2

  Oui, pour ma part, je pense qu'effectivement, j'aime bien l'idée de repenser peut-être ou d'étendre le principe de design system. C'est-à-dire que le design system ne va plus être juste un outil UX, UI, mais vraiment au-delà de ça. La façon d'aller chercher des données ou autre, de le centraliser, parce que ça ne sert à rien de refaire 15 fois la même chose. Et je pense qu'en fait, c'est tout simplement de réinventer ce qui existe déjà avec le principe de microservice et de comment ça fonctionne, l'orchestration, etc. Au final, ça va être la même chose. On le connaît déjà, on le sait. Il y aura sûrement des petites adaptations à faire, mais il y aura ce principe de gérer ça. Par contre, ce qui est clair et net... c'est que ça peut aller très vite. C'est-à-dire que ça peut monter vraiment en nombre énorme suivant l'entreprise. Aujourd'hui, il y a des entreprises, 160 000 employés, il pourrait y avoir 40 000 petites applications comme ça. On n'a rien de temps. Ça peut aller très, très vite. Et donc, c'est clair que la clé, de toute façon, c'est l'automatisation de toute cette chaîne qui permet de le faire. Et je pense qu'il faut aussi voir qu'il y a un monde nous aussi on va avoir... des applications qui sont gérées dans le SI de l'entreprise, mais aussi des applications qui vont être développées, gérées et qui vont tourner sur le poste de chacun. Et donc ça aussi, il faut trouver un moyen de pouvoir le voir, le savoir. Quelles sont les limites de la sécurisation de ça qui sont possibles ? Ça, aujourd'hui, je ne sais pas répondre. Mais je pense qu'aujourd'hui, on ne se rend pas compte à quel point, même déjà maintenant, il y a des gens qui font tourner des programmes vibe codés. qui n'ont jamais touché de développement avant, mais sur leur propre machine et qui sont complètement transparents au reste de l'entreprise. Donc je pense que ça, c'est un point aussi très important auquel il faut faire attention.

• Speaker #1

  Alors, dernière question avant de conclure. Pour Manon et Hubert, la question qui va se poser, c'est... Si demain tout le monde peut produire des applications et qu'on construit des design systems et des harnais pour pouvoir faire en sorte que les applications soient plutôt correctes et plutôt solides, c'est quoi notre rôle ? C'est quoi le rôle des spécialistes en création de logiciels sur mesure ? Toute cette expérience qu'on a accumulée sert à quoi dans le monde de demain ?

• Speaker #4

  Je pense qu'on a encore un peu le temps de tout mettre en place correctement dans les entreprises. Ça nous laisse aller au moins deux ans, je pense. Peut-être que ça ira plus vite, mais bon.

• Speaker #1

  On a encore super longtemps, deux ans.

• Speaker #4

  Deux ans, c'est long. Mais déjà, coordonner tout ça, il va falloir coordonner. Et puis, moi, j'ai l'impression qu'on a notre expertise qui nous sert aujourd'hui. Mais l'expertise que j'utilise le plus, c'est vraiment le découpage en petits problèmes, savoir découper en petits problèmes. Et puis, un peu comme on le faisait avant, même quand on écrivait du code, on découpe tout en petits problèmes. J'ai l'impression que c'est cette compétence-là que j'utilise le plus aujourd'hui dans ce nouveau contexte.

• Speaker #0

  Oui, tout à fait d'accord. J'aime bien l'approche microservice ou design system pour l'ensemble des couches du logiciel. notre expérience va servir aussi à construire cette librairie ou bibliothèque ou platform engineering qui sera à disposition de tous ces nouveaux, ces néo-développeurs et il y a un truc que je voulais ajouter, c'est aussi ce nombre de importants d'applications, ça va aussi peut-être obliger d'aller plus vers les standards. Il y a eu depuis toujours dans le monde du logiciel, des éditeurs qui sont partis dans des niches un petit peu, qui ont fermé leurs clients dans des solutions complètement verrouillées. Et du petit éditeur montpellierain à un gros fabricant de RP américain ou allemand, c'est tous les mêmes. Et donc, je pense que ce changement du coût de la ligne de code, en gros, fait qu'on revient un peu les pieds sur terre et on va essayer de ne pas reinventer la roue, utiliser des briques, mettre des choses en commun. Et tous les systèmes de normalisation pour les échanges ou pour définir des métiers vont servir pour faire cohabiter des briques d'un adéco avec un autre transporteur, un autre déménageur, parce qu'ils ont mis des conventions sur la notion d'un déménagement. Les briques de Lego, c'était la ligne de code avant, et maintenant, ça va être des briques fonctionnelles.

• Speaker #2

  Pour rebondir là-dessus, je suis tout à fait d'accord. Je pense que l'ouverture, l'open data, les API ouvertes, etc., sont hyper importantes. Moi, par exemple, j'en ai parlé tout à l'heure, mais un des premiers trucs que font la plupart des gens sur Internet quand ils commencent à rentrer là-dedans, c'est des applications pour leur usage au quotidien, au niveau perso. Je parlais du Mealplan, par exemple, de faire son planning. pour faire ses courses, etc. Pour sortir ça de la tête. Et moi, en discutant avec pas mal de gens sur Reddit, notamment, dans ce domaine-là, je me suis rendu compte d'un truc. C'est que, par exemple, une enseigne... Je ne sais pas si on n'est pas à la télé, je peux citer l'enseigne.

• Speaker #1

  C'est ce que tu veux.

• Speaker #2

  Ils ne vont pas te faire un procès.

• Speaker #1

  Il n'y a pas de sponsor. C'est que Exfabricar le sponsor, ici.

• Speaker #2

  Mais, par exemple, une enseigne comme Leclerc fait tout son possible pour arrêter les bottes. Pour qu'ils ne puissent pas... passer des commandes, passer leur course. Donc en fait, il y a plein de gens qui ont changé et qui font leur course ailleurs, là où justement leur agent peut faire la commande, par rapport à leur mille-plaines. Donc il y a un vrai sujet comme ça, il ne faut pas se protéger de ça, je pense, quand on est dans l'entreprise, mais au contraire l'accepter, travailler, parce que c'est du business supplémentaire, et ce n'est pas, au contraire, ça ne va pas être quelque chose de néfaste pour l'entreprise.

• Speaker #3

  Moi, je vais aider. Un point, enfin deux. Le premier, c'est que je pense que notre rôle va être pas mal dans l'accompagnement, dans cette transformation en fait, dans l'arrivée, par rapport aux expertises et aux gens qui font du logiciel depuis longtemps. Il y a aussi, pour moi, beaucoup de problématiques au niveau de la santé, de la santé mentale avec tous ces outils. Tout ce gouffre, cette vitesse, cette rapidité, ce côté où on détache. On enlève de l'humain une partie aussi de soi, ça crée plein de problématiques presque philosophiques. Et là du coup je pense qu'il y a un vrai rôle d'accompagnement pour que cette démarche ne soit pas supplie, où on ait ce sentiment de ne pas pouvoir contrôler, d'entrer dans cette machine concrètement. Ça c'était le premier. Le deuxième c'est je pense qu'il y a un vrai rôle, enfin il y a un développement qui va aller au niveau de l'entrepreneuriat. C'est-à-dire que là où les personnes étaient figées dans un poste, dans un salarié, avec une fonction spécifique, Le fait qu'il n'y ait plus de frontières, plus de barrières entre les différentes personnes, ça va les amener à commencer à être cross-fonctionnels, d'aller de plus en plus loin, à rechercher, à apporter de l'impact et de la valeur, et du coup de se rapprocher très naturellement de ce principe d'entrepreneuriat. Et c'est aussi beaucoup ce qu'on voit, notamment par exemple aux Etats-Unis, les solo-builders ou les personnes comme ça qui vont développer des structures grâce à l'IA et qui vont mettre leurs idées. Je pense que dans le futur, on aura vraiment toute une génération de personnes où le salarié va évoluer vers cette construction de produits pour alimenter l'ensemble de l'écosystème tech.

• Speaker #1

  Pour finir, une dernière question. Une question où il faut avoir une réponse courte. En expliquant, c'est quoi le garde-fou qu'il faut que la personne qui nous écoute, pour tous ceux qui regardent cette vidéo, doit mettre en place lundi matin, pour essayer d'accompagner dans le bon sens ce changement qui nous arrive, à nous, professionnels de l'IT. Qu'est-ce que tu fais, toi, tes grands patrons d'une boîte, qu'est-ce que tu fais lundi matin ? Vas-y, je te laisse commencer, Constantin. Alors, je pense que...

• Speaker #0

  Il y a un côté peut-être un peu audit à faire, c'est de se dire, ok, en fait, faisons l'expérience. On va demander à quelqu'un de faire une application pour laquelle il a une idée, et de le regarder faire, presque, pour voir justement qu'est-ce qui peut poser problème, où est-ce qu'il est bloqué, est-ce qu'on permet de le faire, etc. Et de voir nos trous dans la raquette, dans toute la chaîne de fabrication. pour, encore une fois, dans le but de voir si tout est en place pour que ce soit fait de la bonne façon, c'est-à-dire dans un cadre sécurisé.

• Speaker #1

  Moi, je me concentrerais potentiellement sur le jugement, enfin, remettre le point là-dessus pour repartager à l'ensemble des équipes, à tout le monde, à quel point c'est important de préserver ce jugement et d'avoir cette forme de conscience quand on travaille sur ces outils pour, effectivement, relire ce qu'on a fait, pour, effectivement... revérifier et s'assurer qu'on garde que ce qui est en train d'être fait, qui est en train d'être généré, préserve notre envie et notre vision globale commune. Et du coup, c'est une sorte de sécurité un peu naturelle, mais que doit faire l'humain hors de toute la sécurité technique. Mais c'est lui le premier garant de ce qui va être généré ensuite.

• Speaker #2

  Moi, je dirais sécuriser d'abord, avant toute initiative, sécuriser le cadre. pour éviter le shadow IT. On l'a vu avec le no-code, où ça partait un peu dans tous les sens. C'est bien, mais en fait, si on arrive à sécuriser avant qu'il ne soit trop tard pour corriger après, autant le faire dans ce sens-là avant de tester autre chose.

• Speaker #3

  Je partage tout ce qui a été dit. Après, nous, on est un peu biaisés parce qu'on est dans la tech et on parle d'il y a trop. Beaucoup, beaucoup. Et dans une entreprise traditionnelle, on va dire, je pense qu'il faut lever des... Levé des peurs. Il y a un côté acculturation et ça va dans le sens aussi de faire comprendre que ce n'est pas magique. Essayer d'expliquer aux plus techniques comment ça fonctionne au minimum, de leur laisser du temps pour chercher, mais effectivement dans un cadre contrôlé. Donc on a l'impression que ça va vite et tout ça, mais il faut aussi se mettre au niveau du commun des mortels, entre guillemets, qui voit ça comme... quelque chose qui fait peur, qui ne comprenne pas, etc. Donc il y a aussi tout ce côté gestion du changement, mais entre guillemets en douceur, en laissant l'initiative que ce soit contrôlée. Et c'est un long chemin qui nous attend pour les prochaines années. Et l'autre, il y a eu la notion, il y a eu une bonne transition sur le côté local aussi. C'est-à-dire qu'on parle des géants américains, etc. Et les nouveaux systèmes, là... On aura notre LLM sur notre poste aussi, de plus en plus. Donc ça fait une super transition pour notre dernier talk.

• Speaker #4

  Merci, merci à tous les quatre. Merci d'avoir participé à cette table ronde. Merci d'avoir assisté à cet événement. Si vous regardez cette vidéo ou vous écoutez un podcast dans votre voiture ou en train de courir, laissez-nous un commentaire. pas parce que vous êtes en train de conduire, vous avez compris mais laissez-nous un commentaire dites-nous votre avis sur les questions qu'on a ouvertes, il y a sûrement d'autres avis à recevoir, on est hyper curieux comme d'habitude vous likez, vous vous abonnez vous partagez et puis à très vite pour un autre contenu sur Rempart en prod, merci Ce qu'il faut retenir, c'est à l'IT d'apporter le bon cadre et pour tenir toutes ces nouvelles applications qui vont arriver. Avant de vous laisser, un petit mot sur ce qu'on fait chez AXABRICA. On conçoit et on construit des logiciels critiques sur mesure de la supply chain, système agentique compris. Et ces logiciels, on s'engage contractuellement à ce qu'ils aboutissent. Contactez-nous via le lien en description. Et n'oubliez pas, le monde se divise en deux catégories, ceux qui suivent en part en prod,