00:00:00[MUSIQUE]
00:00:21>> Bonjour à tous, bon après-midi.
00:00:22Je vais commencer ma présentation par une petite confession.
00:00:26J'ai déployé du code que je ne comprenais pas tout à fait.
00:00:29Généré, testé, mis en production, mais incapable d'expliquer son fonctionnement.
00:00:33Et le truc, c'est que je parie que c'est aussi votre cas à tous.
00:00:37>> [RIRES]
00:00:40>> Maintenant qu'on peut tous admettre qu'on déploie
00:00:41du code qu'on ne comprend plus, je veux faire un petit voyage,
00:00:44pour voir comment on en est arrivés là.
00:00:46D'abord, regardons l'histoire, car elle a tendance à se répéter.
00:00:50Ensuite, nous sommes tombés dans un piège.
00:00:52Nous avons confondu "facile" et "simple".
00:00:55Enfin, il existe une solution, mais elle exige de ne pas sous-traiter notre réflexion.
00:01:00J'ai passé ces dernières années chez Netflix à pousser l'adoption des outils d'IA.
00:01:05Et je dois dire que l'accélération est absolument réelle.
00:01:07Des tâches du backlog qui prenaient des jours ne prennent plus que quelques heures.
00:01:10Et de lourds refactorings en attente depuis des années sont enfin réalisés.
00:01:15Cependant, il y a un bémol.
00:01:16Les gros systèmes de production échouent toujours de manière inattendue.
00:01:19Regardez ce qui est arrivé à Cloudflare récemment.
00:01:21Quand ça arrive, vous avez intérêt à comprendre le code que vous débuguez.
00:01:23Le problème, c'est qu'on génère du code à une telle vitesse et un tel volume,
00:01:28que notre compréhension a du mal à suivre.
00:01:29Et je sais de quoi je parle, je l'ai fait moi-même.
00:01:34J'ai généré plein de code, je l'ai regardé en me disant : "Je n'ai aucune idée de ce que ça fait".
00:01:39Mais les tests passaient, ça marchait, alors je l'ai envoyé.
00:01:41Le fait est que ce n'est pas vraiment nouveau.
00:01:44Chaque génération d'ingénieurs logiciel finit par heurter un mur
00:01:48où la complexité du logiciel dépasse sa capacité de gestion.
00:01:50Nous ne sommes pas les premiers à affronter une crise du logiciel,
00:01:52mais nous sommes les premiers à l'affronter à cette échelle de génération infinie.
00:01:56Prenons donc un peu de recul pour voir où tout cela a commencé.
00:01:58Fin des années 60, début 70, des informaticiens brillants
00:02:03se sont réunis et ont dit : "Hé, on est en pleine crise du logiciel".
00:02:06La demande est énorme, et pourtant nous n'arrivons pas à suivre.
00:02:11Les projets durent trop longtemps, c'est juste trop lent.
00:02:15On ne fait pas du bon travail.
00:02:16Dijkstra a alors eu une citation remarquable.
00:02:20Il a dit, pour paraphraser : "Quand nous avions des ordinateurs peu puissants,
00:02:23la programmation était un problème mineur.
00:02:26Maintenant que nous avons des ordinateurs géants, programmer est devenu un problème géant".
00:02:31Il expliquait que si la puissance matérielle a été multipliée par 1 000,
00:02:34les besoins de la société en logiciels ont crû en proportion.
00:02:37C'est donc à nous, les programmeurs, de trouver l'équilibre entre les moyens et les fins,
00:02:41pour supporter une telle quantité de logiciels.
00:02:43Et ce cycle ne cesse de se répéter.
00:02:47Dans les années 70, le langage C arrive pour écrire de plus gros systèmes.
00:02:50Dans les années 80, le PC arrive, tout le monde peut coder.
00:02:53Dans les années 90, c'est l'avènement de l'orienté objet.
00:02:56Des hiérarchies infernales par héritage, merci Java pour ça.
00:03:00Dans les années 2000, l'Agile arrive, avec ses sprints
00:03:03et ses Scrum Masters pour nous diriger ; fini le cycle en V.
00:03:06Dans les années 2010, on a eu le cloud, le mobile, le DevOps,
00:03:09le logiciel a véritablement conquis le monde.
00:03:10Et aujourd'hui, on a l'IA : Copilot, Cursor, Claude, Codex, Gemini...
00:03:17On peut générer du code aussi vite qu'on le décrit.
00:03:19Le schéma continue, mais l'échelle a changé, elle est désormais infinie.
00:03:23Fred Brooks, célèbre pour "Le Mythe du mois-homme",
00:03:29a aussi écrit en 1986 un article intitulé "No Silver Bullet".
00:03:32Il y soutenait qu'aucune innovation unique n'apporterait
00:03:36un gain de productivité logicielle d'un ordre de grandeur.
00:03:38Pourquoi ?
00:03:40Parce que, selon lui, le plus dur n'était pas la mécanique du code, la syntaxe,
00:03:44la saisie ou le code répétitif.
00:03:45C'était de comprendre le problème réel et de concevoir la solution.
00:03:49Aucun outil ne peut éliminer cette difficulté fondamentale.
00:03:52Chaque outil créé jusqu'ici facilite la mécanique.
00:03:55Mais le défi central,
00:03:57comprendre quoi construire et comment, reste tout aussi difficile.
00:04:00Si le problème n'est pas dans la mécanique, pourquoi s'obstiner à l'optimiser ?
00:04:06Comment des ingénieurs expérimentés finissent-ils avec du code qu'ils ne comprennent pas ?
00:04:09La réponse réside, je pense, dans deux mots que l'on confond souvent : simple et facile.
00:04:14On a tendance à les utiliser l'un pour l'autre,
00:04:16alors qu'ils désignent des concepts totalement différents.
00:04:18On m'a démasqué au dîner des conférenciers comme étant un adepte de Clojure.
00:04:21C'est assez parlant ici.
00:04:23Mais Rich Hickey, le créateur du langage Clojure,
00:04:25a expliqué cela dans sa conférence de 2011, "Simple Made Easy".
00:04:29Il définit le "simple" comme ce qui n'a qu'un seul pli, une seule tresse, sans enchevêtrement.
00:04:33Chaque pièce fait une seule chose et ne s'entrelace pas avec les autres.
00:04:36Il définit le "facile" comme ce qui est adjacent, à portée de main.
00:04:39Ce qu'on peut obtenir sans effort.
00:04:41Copier, coller, déployer.
00:04:43Le simple concerne la structure.
00:04:45Le facile concerne la proximité.
00:04:48Le fait est qu'on ne rend pas une chose simple par simple volonté.
00:04:51La simplicité exige de la réflexion, de la conception et du démêlage.
00:04:54Mais on peut toujours rendre une chose plus facile.
00:04:56Il suffit de la rapprocher.
00:04:57Installer un paquet, le générer par IA, copier une solution sur Stack Overflow.
00:05:03C'est dans la nature humaine de prendre le chemin de la facilité.
00:05:06Nous sommes programmés pour ça.
00:05:07Comme je l'ai dit, copier sur Stack Overflow, c'est direct.
00:05:10Un framework qui gère tout par magie, on l'installe et c'est parti.
00:05:14Mais facile ne veut pas dire simple.
00:05:15Facile signifie que vous pouvez ajouter des éléments rapidement à votre système.
00:05:18Simple signifie que vous pouvez comprendre le travail que vous avez accompli.
00:05:20Chaque fois qu'on choisit la facilité, on privilégie la vitesse immédiate au détriment de la complexité future.
00:05:24Et honnêtement, ce compromis fonctionnait plutôt bien avant.
00:05:27La complexité s'accumulait assez lentement pour nous laisser
00:05:31le temps de refactoriser, de repenser et de reconstruire si besoin.
00:05:34Je pense que l'IA a brisé cet équilibre.
00:05:36Parce que c'est le bouton "facile" par excellence.
00:05:37Elle rend le chemin de la facilité si fluide
00:05:38qu'on n'envisage même plus le chemin de la simplicité.
00:05:41Pourquoi réfléchir à l'architecture quand le code apparaît instantanément ?
00:05:44Laissez-moi vous montrer comment ça se passe.
00:05:47Comment une tâche simple devient un nid à complexité
00:05:50via cette interface conversationnelle qu'on adore tous.
00:05:52C'est un exemple fictif, mais disons qu'on a notre application,
00:05:55et qu'on veut y ajouter de l'authentification.
00:05:57On demande "ajoute l'auth", et on obtient un beau fichier auth.js tout propre.
00:06:01On itère quelques fois, on arrive au message numéro cinq.
00:06:02On se dit : "OK, super, on va aussi ajouter l'OAuth maintenant",
00:06:04parce qu'on a déjà auth.js et OAuth.js.
00:06:07On continue d'itérer, et on s'aperçoit que les sessions sont cassées.
00:06:11Et on se retrouve avec plein de conflits.
00:06:12Arrivé à la 20ème étape, ce n'est plus vraiment une discussion.
00:06:15Vous gérez des contextes devenus si complexes que même vous,
00:06:18vous ne vous rappelez plus de toutes les contraintes ajoutées.
00:06:20Du code mort issu d'approches abandonnées.
00:06:22Des tests qu'on a bricolés juste pour qu'ils passent.
00:06:25Des bribes de trois solutions différentes car on finit par dire : "Attends, en fait..."
00:06:28Chaque nouvelle instruction écrase les schémas architecturaux.
00:06:31On a dit "fais marcher l'auth", et ça a marché.
00:06:33On a dit "corrige cette erreur", et ça a été fait.
00:06:35Il n'y a aucune résistance aux mauvaises décisions d'architecture.
00:06:38Le code se transforme simplement pour satisfaire votre dernière requête.
00:06:40Chaque interaction privilégie le facile au détriment du simple.
00:06:43Et le facile amène toujours plus de complexité.
00:06:46On le sait bien, mais quand le chemin facile est à ce point accessible, on le prend.
00:06:50Et la complexité va s'accumuler jusqu'à ce qu'il soit trop tard.
00:06:52L'IA pousse vraiment la facilité à son extrême logique.
00:06:58Décidez de ce que vous voulez, obtenez le code instantanément.
00:07:00Mais voici le danger.
00:07:02Le code généré traite tous les modèles de votre base de code de la même manière.
00:07:06Quand un agent analyse votre code, chaque ligne devient un modèle à préserver.
00:07:10La vérification d'authentification à la ligne 47 ? C'est un modèle." : "La vérification d'authentification à la ligne 47, c'est un modèle.
00:07:13Ce code gRPC bizarre qui se comporte comme du GraphQL que j'ai pu ajouter en 2019 ?
00:07:18C'est aussi un modèle.
00:07:19La dette technique n'est pas vue comme une dette, c'est juste du code en plus.
00:07:22Le vrai problème ici, c'est la complexité.
00:07:25Je sais que j'ai beaucoup utilisé ce mot sans vraiment le définir.
00:07:29Le meilleur moyen de le voir, c'est comme l'opposé de la simplicité.
00:07:31Cela signifie simplement "entrelacé".
00:07:33Et quand les choses sont complexes, tout touche à tout.
00:07:36On ne peut pas changer une chose sans en impacter dix autres.
00:07:41Revenons à l'article "No Silver Bullet" de Fred Brooks.
00:07:43Il y identifiait deux types principaux de complexité dans tout système.
00:07:47Il y a la complexité essentielle, qui est la difficulté fondamentale
00:07:51du problème réel que vous essayez de résoudre.
00:07:53Les utilisateurs doivent payer, les commandes doivent être honorées.
00:07:56C'est la raison d'être de votre système logiciel.
00:08:00Et deuxièmement, il y a la complexité accidentelle.
00:08:03Tout ce qu'on a ajouté en cours de route : contournements, code défensif,
00:08:06frameworks, abstractions qui semblaient logiques il y a un temps.
00:08:09C'est tout ce qu'on a assemblé pour faire fonctionner le code.
00:08:11Dans une base de code réelle, ces deux types de complexité sont partout.
00:08:16Et ils s'entremêlent tellement que les séparer demande du contexte,
00:08:19de l'historique et de l'expérience.
00:08:20Le résultat généré ne fait aucune distinction de ce genre.
00:08:24Ainsi, chaque modèle finit par être préservé.
00:08:26Voici un exemple concret tiré de notre travail chez Netflix.
00:08:32J'ai un système avec une couche d'abstraction située entre notre vieux
00:08:35code d'autorisation écrit il y a environ cinq ans, et un nouveau système centralisé.
00:08:41On n'avait pas le temps de tout reconstruire, alors
00:08:42on a juste mis une cale entre les deux.
00:08:44Avec l'IA, c'est une excellente occasion de refactoriser notre code
00:08:47pour utiliser le nouveau système directement. Ça semble simple, non ?
00:08:50Eh bien non. Le vieux code était tellement couplé à ses modèles d'autorisation...
00:08:56On avait des vérifications de permissions mêlées à la logique métier,
00:08:59des rôles ancrés dans les modèles de données, et des appels d'auth partout.
00:09:03L'agent commençait à refactoriser quelques fichiers, puis
00:09:07tombait sur une dépendance impossible à démêler, et partait en vrille.
00:09:10Ou pire, il essayait de préserver l'ancienne logique du vieux système
00:09:16en la recréant avec le nouveau, ce qui n'est vraiment pas idéal.
00:09:19Le fait est qu'il ne voyait pas les coutures.
00:09:23Il ne distinguait pas où finissait le métier et où commençait l'auth.
00:09:26Tout était si emmêlé que même avec une information parfaite,
00:09:30l'IA ne trouvait pas de chemin propre.
00:09:33Quand votre complexité accidentelle est à ce point entrelacée,
00:09:35l'IA n'est pas la meilleure aide pour améliorer la situation.
00:09:38J'ai trouvé qu'elle ne faisait qu'ajouter des couches supplémentaires.
00:09:40Nous, on peut faire la différence, du moins quand on ralentit pour réfléchir.
00:09:45On sait quels modèles sont essentiels et
00:09:47lesquels sont juste la solution de quelqu'un d'il y a quelques années.
00:09:50Nous possédons le contexte que l'IA ne peut pas deviner, mais
00:09:53seulement si on prend le temps de faire ces distinctions avant de commencer.
00:09:56Alors, comment s'y prend-on concrètement ?
00:10:01Comment séparer l'accidentel de l'essentiel face à une base de code immense ?
00:10:04Celle sur laquelle je travaille chez Netflix fait environ un million de lignes de Java,
00:10:07et le service principal comptait cinq millions de tokens la dernière fois que j'ai vérifié.
00:10:10Aucune fenêtre de contexte à laquelle j'ai accès ne peut tout contenir.
00:10:13Alors, pour travailler dessus, j'ai d'abord pensé :
00:10:17"Hé, je pourrais peut-être copier de larges pans de code dans le contexte"
00:10:19pour voir si les modèles allaient émerger,
00:10:23et si l'IA arriverait à comprendre ce qui se passait.
00:10:24Mais comme pour le refactoring d'autorisation de tout à l'heure,
00:10:26le résultat s'est juste perdu dans sa propre complexité.
00:10:29le résultat s'est perdu dans sa propre complexité.
00:10:31J'ai donc été contraint de procéder autrement.
00:10:34J'ai dû choisir quoi inclure : documents de conception, architecture, diagrammes...
00:10:37les interfaces clés, tout ce qu'on peut imaginer.
00:10:39Et prendre le temps de rédiger les exigences d'interaction des composants
00:10:42ainsi que les modèles à suivre.
00:10:43En fait, je rédigeais une spécification.
00:10:45Cinq millions de jetons sont devenus 2 000 mots de spécifications.
00:10:49Et pour aller encore plus loin, j'ai pris ces specs
00:10:52pour créer une série d'étapes de code précises à exécuter.
00:10:55Pas d'instructions vagues, juste une séquence précise d'opérations.
00:10:58J'ai trouvé que cela produisait un code bien plus propre, ciblé et compréhensible.
00:11:02Je l'ai donc d'abord défini, puis j'ai planifié sa propre exécution.
00:11:05C'est devenu l'approche que j'ai appelée « compression de contexte » il y a quelque temps.
00:11:11Mais vous pouvez l'appeler ingénierie de contexte, développement par spectre...
00:11:13peu importe.
00:11:15Le nom n'a pas d'importance.
00:11:16Ce qui compte, c'est que la réflexion et la planification deviennent l'essentiel du travail.
00:11:20Laissez-moi vous expliquer comment cela fonctionne en pratique.
00:11:22Il y a l'étape 1, la phase une : la recherche.
00:11:26Je commence par tout lui soumettre d'emblée.
00:11:28Diagrammes d'architecture, documentation, fils de discussion Slack.
00:11:31On en a déjà parlé à maintes reprises.
00:11:32Mais apportez vraiment autant de contexte que possible
00:11:35par rapport aux changements que vous effectuez.
00:11:36Ensuite, utilisez l'agent pour analyser la base de code
00:11:39et cartographier les composants et les dépendances.
00:11:42Ce ne doit pas être un processus ponctuel.
00:11:43J'aime bien sonder, demander : « Qu'en est-il du cache ? »
00:11:46« Comment gère-t-il les erreurs ? »
00:11:47Et quand son analyse est fausse, je la corrige.
00:11:49S'il manque de contexte, je le lui fournis.
00:11:51Chaque itération affine son analyse.
00:11:55Le résultat final est un document de recherche unique.
00:11:57Voici ce qui existe, voici ce qui est relié à quoi,
00:11:59et voici ce que votre modification va impacter.
00:12:01Des heures d'exploration sont compressées en quelques minutes de lecture.
00:12:03Dex l'a mentionné ce matin, mais le point de contrôle humain est ici crucial.
00:12:09C'est là que vous validez l'analyse par rapport à la réalité,
00:12:12le moment le plus déterminant de tout le processus.
00:12:15Détectez les erreurs ici pour éviter des catastrophes plus tard.
00:12:17Passons à la phase deux.
00:12:20Maintenant que vous avez des recherches valides en main,
00:12:22nous créons un plan d'implémentation détaillé : structure réelle du code,
00:12:25signatures de fonctions, définitions de types, flux de données.
00:12:28Il faut que n'importe quel développeur puisse le suivre.
00:12:30C'est un peu comme du coloriage par numéros.
00:12:32Vous devriez pouvoir le donner à votre ingénieur le plus junior et dire : « Fais ça ».
00:12:35S'il le copie ligne par ligne, cela devrait fonctionner tout simplement.
00:12:38C'est à cette étape que nous prenons les décisions architecturales importantes.
00:12:43On s'assure que la logique complexe est correcte.
00:12:45On vérifie que les exigences métier suivent les bonnes pratiques.
00:12:50On veille aux limites des services, à une séparation nette,
00:12:52et on évite tout couplage inutile.
00:12:54Nous repérons les problèmes avant qu'ils n'arrivent car nous les avons vécus.
00:12:57L'IA n'a pas cette possibilité.
00:12:59Elle traite chaque modèle comme une exigence.
00:13:01La vraie magie de cette étape réside dans la vitesse de révision.
00:13:05Nous pouvons valider ce plan en quelques minutes et savoir exactement ce qui va être construit.
00:13:10Et pour suivre la cadence à laquelle nous voulons générer du code,
00:13:13nous devons être capables de comprendre ce que nous faisons tout aussi vite.
00:13:18Enfin, nous avons l'implémentation, et maintenant que nous avons un plan clair
00:13:22appuyé par des recherches précises, cette phase devrait être assez simple.
00:13:26Et c'est tout l'intérêt.
00:13:28Quand l'IA a une spécification claire à suivre, le contexte reste propre
00:13:31et ciblé.
00:13:32Nous avons évité la spirale de complexité des longues conversations.
00:13:36Au lieu de 50 messages de code évolutif,
00:13:38nous avons trois résultats ciblés, chacun validé avant de continuer.
00:13:41Pas d'approches abandonnées, pas de modèles contradictoires,
00:13:44pas de moments « attends, en fait... » qui laissent du code mort partout.
00:13:48Pour moi, le vrai bénéfice est qu'on peut utiliser un agent en arrière-plan
00:13:52pour faire une grande partie du travail, car toute la réflexion a été faite en amont.
00:13:56Il peut lancer l'implémentation, vous pouvez passer à autre chose,
00:13:59puis revenir pour la révision.
00:14:01Et vous pouvez réviser rapidement car vous vérifiez juste la conformité au plan,
00:14:04sans essayer de comprendre si des choses ont été inventées.
00:14:07Le point essentiel ici est que nous n'utilisons pas l'IA pour réfléchir à notre place.
00:14:12Nous l'utilisons pour accélérer les parties mécaniques
00:14:15tout en conservant notre capacité à comprendre.
00:14:17La recherche est plus rapide, la planification plus approfondie et l'implémentation plus propre.
00:14:21Cependant, la réflexion, la synthèse et le jugement nous incombent toujours.
00:14:26Alors, vous vous souvenez de cette refonte d'autorisation que l'IA ne pouvait pas gérer ?
00:14:34Le fait est que nous y travaillons actuellement et
00:14:37nous commençons à faire de bons progrès.
00:14:39Et ce n'est pas parce que nous avons trouvé de meilleurs prompts.
00:14:42Nous avons réalisé qu'on ne pouvait même pas passer directement à la recherche ou au plan.
00:14:45Nous avons dû...
00:14:46en fait, faire ce changement nous-mêmes, à la main.
00:14:49Sans IA, juste en lisant le code, en comprenant les dépendances,
00:14:52et en faisant des modifications pour voir ce qui cassait.
00:14:53Cette migration manuelle était, honnêtement, une corvée, mais elle était cruciale.
00:14:59Elle a révélé toutes les contraintes cachées, les invariants à respecter,
00:15:02et les services qui planteraient si l'authentification changeait.
00:15:05Des choses qu'aucune analyse de code n'aurait pu faire remonter.
00:15:09Puis, nous avons intégré la pull request de cette migration manuelle
00:15:14dans notre processus de recherche pour servir de base à la suite.
00:15:19L'IA a pu alors voir à quoi ressemble une migration propre.
00:15:23Comme chaque entité est légèrement différente, nous devons l'interroger
00:15:27et dire : « Hé, qu'est-ce qu'on fait pour ça ? »
00:15:29Certaines choses sont chiffrées, d'autres non.
00:15:32On a dû fournir ce contexte supplémentaire à chaque fois par itération.
00:15:35Alors, et seulement alors, nous avons pu générer un plan qui pourrait marcher du premier coup.
00:15:41Et le mot clé ici est « pourrait », car nous validons toujours,
00:15:45ajustons encore et découvrons toujours des cas particuliers.
00:15:47L'approche en trois phases n'est pas magique.
00:15:55Elle ne fonctionne que parce que nous avons fait cette migration à la main.
00:15:57On a dû mériter la compréhension avant de l'encoder dans notre processus.
00:16:01Je pense toujours qu'il n'y a pas de solution miracle.
00:16:02Ni de meilleurs prompts, ni de meilleurs modèles, ni même de meilleures specs.
00:16:06Juste le travail de comprendre votre système assez profondément
00:16:09pour y apporter des modifications en toute sécurité.
00:16:11Alors pourquoi s'infliger tout cela ?
00:16:15Pourquoi ne pas simplement itérer avec l'IA jusqu'à ce que ça marche ?
00:16:18Finalement, les modèles deviennent assez puissants et ça finit par marcher.
00:16:21Le problème pour moi, c'est que « ça marche » ne suffit pas.
00:16:24Il y a une différence entre un code qui passe les tests et un code qui survit
00:16:27en production.
00:16:28Entre des systèmes qui fonctionnent aujourd'hui
00:16:31et des systèmes qui pourront être modifiés par quelqu'un d'autre à l'avenir.
00:16:34Le vrai problème ici est un fossé de connaissances.
00:16:38Quand l'IA peut générer des milliers de lignes de code en quelques secondes,
00:16:41les comprendre pourrait vous prendre des heures, voire des jours si c'est complexe.
00:16:45Ou peut-être jamais, si c'est vraiment trop emmêlé.
00:16:48Voici un point dont peu de gens parlent actuellement.
00:16:52Chaque fois qu'on zappe la réflexion pour suivre la vitesse de génération,
00:16:56on ne fait pas qu'ajouter du code qu'on ne comprend pas.
00:16:58On perd notre capacité à identifier les problèmes.
00:17:00Cet instinct qui dit : « Hé, ça devient complexe »,
00:17:03il s'atrophie quand on ne comprend plus son propre système.
00:17:09La reconnaissance des formes vient de l'expérience.
00:17:11Si je repère une architecture dangereuse,
00:17:12c'est parce que c'est moi qui étais debout à 3 heures du matin pour gérer ça.
00:17:16Quand je pousse pour des solutions plus simples,
00:17:17c'est parce que j'ai dû maintenir l'alternative laissée par quelqu'un d'autre.
00:17:21L'IA génère ce que vous lui demandez.
00:17:23Elle n'encode pas les leçons des échecs passés.
00:17:25L'approche en trois phases comble ce fossé.
00:17:29Elle compresse la compréhension en documents révisables à la vitesse de génération.
00:17:33Sans cela, nous accumulons de la complexité plus vite que nous ne pouvons
00:17:37la saisir.
00:17:39L'IA change tout dans notre façon d'écrire du code, mais honnêtement,
00:17:44je ne pense pas qu'elle change quoi que ce soit aux raisons pour lesquelles un logiciel échoue.
00:17:47Chaque génération a affronté sa propre crise logicielle.
00:17:50Celle de Dijkstra l'a fait en créant la discipline du génie logiciel,
00:17:54et nous affrontons la nôtre avec la génération de code infinie.
00:17:56Je ne pense pas que la solution soit un autre outil ou une autre méthodologie.
00:18:01C'est de se souvenir de ce qu'on a toujours su : le logiciel est une entreprise humaine.
00:18:05Le plus dur n'a jamais été de taper le code.
00:18:06C'était de savoir quoi taper au départ.
00:18:09Les développeurs qui réussiront ne seront pas juste ceux qui génèrent le plus de code.
00:18:13Ce seront ceux qui comprennent ce qu'ils construisent,
00:18:15qui voient encore les coutures, et qui réalisent quand ils sont
00:18:18en train de résoudre le mauvais problème.
00:18:19Ça, c'est encore nous.
00:18:20Ça ne sera que nous.
00:18:21Je voudrais finir sur une question, et je ne pense pas que ce soit de savoir
00:18:25si nous utiliserons l'IA ou non.
00:18:26C'est déjà une certitude.
00:18:28Le train est déjà en marche.
00:18:30Pour moi, la question est de savoir si nous comprendrons encore nos propres systèmes
00:18:33quand l'IA écrira l'essentiel de notre code.
00:18:35Merci.
00:18:37>> [APPLAUDISSEMENTS]
00:18:39[MUSIQUE]