C'est un réel plaisir de vous voir. Comme il s'agit d'une école de start-up, ce que je souhaite faire aujourd'hui, c'est partager avec vous quelques leçons apprises lors de la création de start-ups au sein de l'AI Fund. Le travail consiste à fournir des capitaux et nous créons en moyenne une start-up par mois. Comme nous co-fondons ces start-ups, nous y écrivons du code, discutons avec les clients, concevons des fonctionnalités et fixons les prix. Par conséquent, nous travaillons beaucoup, non seulement en observant comment les autres créent des start-ups, mais aussi en y participant activement, en les créant aux côtés des entrepreneurs.

Aujourd'hui, je souhaite partager avec vous quelques leçons apprises au cours du processus entrepreneurial, notamment autour de cette technologie d'intelligence artificielle en constante évolution et de ce que les machines peuvent accomplir. Cela se concentrera sur le thème de la vitesse. Pour ceux qui veulent créer une entreprise, je pense qu'un prédicteur puissant de succès est la vitesse d'exécution. En fait, je respecte énormément les entrepreneurs et les cadres capables d'accomplir des tâches rapidement. Les technologies d'IA performantes permettent aux start-ups de se développer plus vite. C'est pourquoi je souhaite partager avec vous certaines de ces meilleures pratiques issues de l'exploration pratique. Celles-ci évoluent tous les deux ou trois mois pour permettre d'acquérir cette vitesse et, je l'espère, vous donner de meilleures chances de réussite.

Avant d'approfondir la question de la vitesse, on m'a demandé : Andrew, où se trouvent les opportunités de start-up ? Voici ce que je considère comme la pile de l'IA. Au niveau le plus bas se trouvent les entreprises de semi-conducteurs, puis le cloud, les hyper-scalers sur lesquels le monde est bâti. De nombreuses entreprises de technologies et de modèles d'IA se construisent par-dessus. Bien que l'excitation et le battage médiatique du public se concentrent sur ces couches technologiques, il s'avère que, presque par définition, la plus grande opportunité doit se trouver dans la couche applicative, car nous avons besoin que les applications génèrent plus de revenus pour pouvoir payer les couches technologiques de base du cloud et des semi-conducteurs. Pour une raison quelconque, les médias et les réseaux sociaux ont tendance à peu parler de la couche applicative. Mais pour ceux qui créent leurs propres start-ups, la plus grande opportunité est presque là. Bien qu'il y ait bien sûr des opportunités à tous les niveaux de la pile.

En ce qui concerne les tendances technologiques de l'IA, beaucoup de choses ont changé l'année dernière. Si vous me demandez quelle est la tendance la plus importante en IA, je dirais l'essor de l'IA agentique. Il y a environ un an et demi, quand j'ai commencé à donner des conférences partout pour essayer de convaincre les gens que les agents d'IA pourraient être une réalité, je n'avais pas réalisé que vers l'été dernier, un groupe de vendeurs s'emparerait du terme pour l'étiqueter sur tout ce qui se trouve en ligne. Cela lui a presque fait perdre de son sens. Mais je veux partager avec vous d'un point de vue technique pourquoi je pense que l'IA agentique est passionnante et importante, et pourquoi elle ouvre encore plus d'opportunités entrepreneuriales. Il s'avère que la façon dont beaucoup d'entre nous utilisent les LLM est de les inciter à générer une sortie. Nous demandons au LLM de produire quelque chose comme si vous demandiez à une personne, ou dans ce cas à une IA, d'écrire un article d'un seul trait du premier au dernier mot, sans utiliser la touche retour arrière. Les humains sont limités par cette approche linéaire, nous ne pouvons donc pas écrire les meilleurs articles ainsi.

Cependant, il s'avère qu'il en va de même pour l'IA. Bien qu'être forcé d'écrire de cette manière linéaire soit difficile, nos LLM s'en sortent étonnamment bien. Avec des flux de travail agentiques, nous pouvons utiliser un système d'IA et lui demander d'écrire d'abord le plan d'un article, puis d'effectuer des recherches sur le web si nécessaire et de récupérer des pages, de les placer dans leur propre contexte, d'écrire une première ébauche, puis de la lire pour la critiquer et la réviser, et ainsi de suite. Nous obtenons ainsi ce flux de travail itératif où votre modèle réfléchit, fait des recherches, effectue des révisions, puis revient pour réfléchir davantage, et ainsi de suite. C'est un peu plus lent, mais cela fournit un meilleur produit de travail. Pour de nombreux projets, l'AI Fund s'est impliqué dans divers domaines, de l'extraction de documents fiscaux complexes aux diagnostics médicaux en passant par le raisonnement sur des documents juridiques complexes. Nous avons constaté que ces flux de travail agentiques font une énorme différence. De nombreux travaux à accomplir et entreprises de valeur à bâtir nécessitent encore d'adopter des flux de travail existants ou nouveaux et de les implémenter dans ces flux de travail agentiques à grande échelle. Pour mettre à jour l'image de la pile, une nouvelle couche d'orchestration d'agents est apparue l'année dernière, aidant les constructeurs d'applications à orchestrer ou coordonner de nombreux appels vers les couches technologiques sous-jacentes. La bonne nouvelle est que la couche d'orchestration facilite la création d'applications. Mais je pense que la couche applicative doit être la couche la plus précieuse de la pile. La conclusion fondamentale reste valable tant que l'on se concentre sur la couche applicative.

Permettez-moi maintenant d'approfondir certaines des meilleures pratiques que j'ai apprises sur la manière dont les start-ups peuvent se développer plus rapidement. Il s'avère qu'au sein de l'AI Fund, nous nous concentrons uniquement sur des idées concrètes. Pour moi, une idée concrète, une idée de produit concrète, c'est être capable de la spécifier en détail pour qu'un ingénieur puisse l'implémenter. Par exemple, si vous dites 'utilisons l'IA pour optimiser les actifs médicaux', ce n'est pas du tout concret, c'est trop vague. Si vous me dites que c'est un logiciel utilisant l'IA pour optimiser les actifs médicaux, différents ingénieurs feront des choses totalement différentes, et parce que ce n'est pas concret, vous ne pouvez pas le construire rapidement, vous n'avez pas de vitesse. À l'inverse, si vous avez une idée concrète comme 'écrivons un logiciel permettant aux hôpitaux de laisser les patients réserver en ligne des créneaux pour les machines IRM afin d'optimiser l'utilisation'. Je ne sais pas si c'est une bonne ou une mauvaise idée, mais elle est concrète. En fait, des entreprises le font déjà, c'est concret. Cela signifie que les ingénieurs peuvent le construire rapidement. Que ce soit une bonne idée ou non, vous le découvrirez vite. Avec des idées concrètes, vous gagnez en vitesse. Ou si quelqu'un dit 'utilisons l'IA pour améliorer la productivité personnelle des e-mails'. Il y a trop d'interprétations, ce n'est pas concret. Mais si quelqu'un dit 'pouvons-nous construire une application intégrée à Gmail pour automatiser des fonctions, utilisons le bon filtrage par invites pour l'ensemble des e-mails', c'est concret. Je sais que je pourrais commencer à le construire cet après-midi. Par conséquent, la concrétude vous apporte de la vitesse. Et pour de nombreux entrepreneurs, la chose difficile est que les idées floues reçoivent souvent beaucoup d'éloges. Si vous dites à tous vos amis 'nous devrions utiliser l'IA pour optimiser l'utilisation des actifs médicaux', tout le monde dira que c'est une bonne idée. Mais en réalité, ce n'est pas une bonne idée, du moins dans le sens où vous ne pouvez pas la construire. Il s'avère que lorsqu'on est vague, on a presque toujours raison. Mais quand on est concret, on peut avoir raison ou tort. Dans les deux cas, c'est bien, car on peut le découvrir plus vite. C'est important pour vous.

En ce qui concerne l'exécution d'idées concrètes, au sein de l'AI Fund, je demande à mon équipe de se concentrer sur des idées concrètes car elles donnent une direction claire. L'équipe peut les construire rapidement et les valider, les prouver ou conclure qu'elles ne fonctionnent pas. Dans tous les cas, c'est bien, car nous pouvons le faire rapidement. Il s'avère que trouver de bonnes idées concrètes nécessite souvent que quelqu'un, probablement un expert du domaine, réfléchisse longuement au problème. Par exemple, avant de fonder Coursera, j'ai passé des années à réfléchir à l'éducation en ligne, à parler aux utilisateurs, en me fiant à mon intuition pour décider de ce que serait une bonne plateforme de technologie éducative. Puis, après ce long processus, parfois appelé réflexion dans le labyrinthe des idées, après une longue réflexion, on s'aperçoit que l'intuition de ceux qui ont réfléchi longuement au problème peut être excellente pour prendre des décisions rapides. Après avoir réfléchi à la question et parlé aux clients pendant longtemps, si vous demandez à cet expert 'dois-je construire cette fonctionnalité ou celle-là ?', l'intuition est une décision instantanée. Cela peut être un très bon substitut, un mécanisme de décision étonnamment bon. Je sais que je travaille dans l'IA et vous pourriez penser que je dirais que nous avons besoin de données. Bien sûr, j'aime les données, mais il s'avère que pour de nombreuses start-ups, l'obtention de données est en réalité un mécanisme de décision lent. Un expert du domaine doté d'une bonne intuition est souvent un meilleur mécanisme pour prendre des décisions rapides. Pour de nombreuses start-ups prospères, à tout moment, vous poursuivez une hypothèse très claire. Les start-ups n'ont pas les ressources pour en essayer dix à la fois, donc choisissez-en une et foncez. Si les données vous disent de perdre confiance en cette idée, c'est tout à fait acceptable. Pivotez simplement immédiatement pour poursuivre une idée concrète totalement différente. On dirait qu'à l'AI Fund, je poursuis une chose avec persévérance jusqu'à ce que le monde me dise que nous avons tort, puis nous changeons d'avis et poursuivons quelque chose de totalement différent avec la même détermination et la même persévérance. J'ai aussi vu un autre modèle : si chaque nouvelle donnée vous fait pivoter, cela peut signifier que vous partez d'une base de connaissances trop fragile. Si chaque conversation change radicalement votre avis, cela signifie peut-être que vous ne connaissez pas assez bien le domaine pour trouver de vraies bonnes idées concrètes. Trouver quelqu'un qui a réfléchi plus longtemps à un sujet pourrait vous donner une meilleure voie et vous permettre d'aller plus vite.

Une autre chose à laquelle je pense souvent est la boucle de rétroaction de la construction. La façon dont nous utilisons l'IA pour aider à construire change rapidement. Ainsi, lorsque vous construisez de nombreuses applications, l'un des plus grands risques est que le marché ne les accepte pas. Beaucoup de start-ups échouent non pas parce que nous ne pouvons pas construire ce que nous voulons, mais parce que nous construisons quelque chose dont personne ne se soucie. C'est pourquoi, de bien des manières, quand je crée des start-ups, en particulier des start-ups d'applications, nous écrivons souvent du logiciel (problème d'ingénierie), puis nous recevons des retours des utilisateurs (problème de gestion de produit), puis nous ajustons notre vision de ce qu'il faut construire en fonction des retours et recommençons à coder. Nous effectuons de nombreuses itérations autour de cette boucle pour trouver l'adéquation produit-marché. Il s'avère qu'avec l'aide du codage par IA, l'ingénierie rapide devient possible. Cette approche propose simplement des solutions plus viables. La vitesse d'ingénierie augmente rapidement et les coûts d'ingénierie chutent. Cela change le mécanisme de propulsion des start-ups autour de cette boucle. Quand je pense aux logiciels que je crée, je les divise en deux grandes catégories. Parfois, je construis des prototypes rapides et bruts pour tester une idée, comme un nouveau chatbot de service client, ou quand nous construisons une IA pour assister sur des documents juridiques, un prototype rapide pour voir si nous pensons que ça fonctionne. L'autre catégorie est l'écriture de logiciels de production maintenables, le maintien de logiciels existants. La production à grande échelle, c'est le code lui-même. Selon les rapports d'analystes auxquels vous faites confiance ou les données rigoureuses sur le sujet, la vitesse d'utilisation de ces systèmes pour écrire du code de qualité production peut augmenter de 30 % à 50 %. Il est difficile de trouver un chiffre précis. Mais pour construire des prototypes rapides et bruts, notre vitesse ne sera pas seulement 50 % plus rapide ; je pense que nous pouvons facilement être 10 fois plus rapides, voire bien plus. Il y a deux raisons à cela : premièrement, lorsque vous construisez un prototype indépendant, il y a moins d'intégration avec l'infrastructure logicielle existante et moins de données héritées nécessaires. Les exigences en matière de fiabilité, d'évolutivité et même de sécurité sont beaucoup plus faibles. Je sais que je ne devrais pas dire aux gens d'écrire du code non sécurisé, mais quand je dis souvent à mon équipe qu'ils doivent écrire du code non sécurisé, c'est parce que si le logiciel ne tourne que sur votre ordinateur portable, alors utiliser du code non sécurisé est acceptable. Bien sûr, une fois qu'il semble fonctionner, assurez-vous qu'il soit sécurisé avant de l'envoyer à d'autres. La fuite de données sensibles est toxique. Assurez donc la sécurité et l'évolutivité avant le lancement. Mais pour les tests, c'est bon. Je vois donc de plus en plus de start-ups déterminer leur direction fondamentale en construisant 20 prototypes pour voir ce qui fonctionne. Je sais qu'il y a une certaine anxiété autour de l'IA, car de nombreuses preuves de concept ne passent pas en production. Mais je pense que même si beaucoup de preuves de concept ne voient pas le jour, c'est en fait acceptable. Je sais que 'agir vite et casser des choses' est un slogan qui a mauvaise réputation parce qu'il casse des choses. Certaines équipes en ont conclu qu'elles ne devaient pas agir trop vite, mais je pense que c'est une erreur. J'ai tendance à dire à mon équipe d'agir vite tout en étant responsable. Il y a en fait de nombreuses façons d'agir vite sans perdre son sens des responsabilités.

En ce qui concerne le domaine du codage assisté par l'IA, il y a trois ans, l'autocomplétion de code a été popularisée par GitHub Copilot. Puis sont apparus des IDE assistés par IA comme Cursor ou Windsurf, qui utilise massivement Cursor. Ensuite, depuis six ou sept mois, une nouvelle génération d'assistants de codage hautement agentiques a émergé. Depuis la sortie de Windsurf, j'utiliserais peut-être des outils différents, car ils évoluent rapidement. Mais je pense que le code de 2024 est une nouvelle génération d'assistance au codage hautement agentique qui peut augmenter considérablement la productivité des développeurs. Il est intéressant de noter qu'il y a une grande différence entre l'utilisation des derniers outils et les générations précédentes. Je constate que mon équipe adopte aujourd'hui une approche de l'ingénierie logicielle très différente de celle d'il y a trois ou six mois. Il est surprenant de voir que nous avions l'habitude de considérer le code comme un artefact précieux car il était difficile à créer. Mais comme le coût de l'ingénierie logicielle a chuté, le code n'est plus un artefact aussi précieux qu'avant. Dans mon équipe, le mois dernier, nous avons entièrement reconstruit la base de code trois fois. Reconstruire entièrement une base de code n'est plus aussi difficile. C'est acceptable avec un nouveau schéma de données car le coût pour le faire a considérablement baissé. Certains d'entre vous connaissent peut-être le terme de Jeff Bezos sur les portes à double sens et à sens unique. Une porte à double sens est une décision où, si vous changez d'avis, il est relativement peu coûteux de revenir en arrière. Une porte à sens unique est une décision dont le changement d'avis est très coûteux ou difficile à inverser. Auparavant, choisir l'architecture logicielle d'une pile technique était une porte à sens unique. Une fois construit sur une pile, avec un schéma de base de données, c'était difficile à changer. Je ne dirais pas que c'est devenu une porte à double sens totale, mais je vois mon équipe changer d'avis après avoir construit pas mal de code sur certaines piles, jeter la base de code et recommencer de zéro sur une nouvelle pile. Nous ne le faisons pas systématiquement, car recommencer a toujours un coût. Mais je vois mon équipe repenser souvent ce qui est une porte à sens unique et ce qui est une porte à double sens, car le coût de l'ingénierie logicielle est maintenant bien plus bas. Au-delà de l'ingénierie logicielle, je pense que c'est le moment idéal pour que tout le monde ait la capacité de construire avec l'IA. L'année dernière, beaucoup ont conseillé de ne pas apprendre à coder sous prétexte que l'IA automatiserait tout. Je pense qu'avec le recul, ce sera considéré comme le pire conseil de carrière de l'histoire. Car à mesure que de meilleurs outils facilitent l'ingénierie logicielle, il y aura plus de gens pour l'exécuter, pas moins. Il y a des décennies, le monde est passé des cartes perforées au clavier et au terminal, ce qui a facilité le codage. Quand nous sommes passés de l'assembleur aux langages de haut niveau comme le C, on disait qu'on n'aurait plus besoin de programmeurs. C'était évidemment faux. Les langages de programmation facilitent le codage, et plus de gens devraient apprendre à coder. J'ai une opinion controversée : je pense que tout le monde, quel que soit son rôle, devrait apprendre à coder. En fait, dans mon équipe, mon directeur financier, le responsable des talents, les recruteurs, le personnel d'accueil, ils savent tous coder. Et je constate qu'ils sont meilleurs dans toutes leurs fonctions car ils savent coder. Je pense être un peu en avance sur la tendance, la plupart des entreprises n'en sont pas encore là. À l'avenir, je pense que si tout le monde peut coder, beaucoup gagneront en efficacité. Je voudrais partager une leçon apprise sur la raison pour laquelle nous devrions inciter les gens à apprendre cela. Quand j'enseignais l'IA générative pour tous sur Coursera, nous devions utiliser Midjourney pour générer des images de fond. Un membre de mon équipe s'y connaissait en art, il pouvait donc utiliser des invites de style, de palettes de couleurs. Il avait un excellent contrôle sur les images générées, donc nous avons fini par utiliser toutes ses images. À l'inverse, je n'y connais rien en art. Donc, quand je générais des images, cela me faisait de jolies photos de robots, mais je n'avais pas le contrôle de mon collaborateur pour générer d'aussi bonnes images. Je pense qu'une des compétences les plus importantes avec les ordinateurs à l'avenir sera d'être capable de leur dire exactement ce que vous voulez. Mieux on connaît les ordinateurs, plus on pourra les commander pour obtenir le résultat voulu. Apprendre à coder ne signifie pas écrire le code soi-même, mais guider l'IA pour qu'elle le fasse pour vous. Il semble que ce soit actuellement la meilleure approche dans mon équipe. L'ingénierie logicielle devient de plus en plus rapide. Une autre dynamique intéressante que je vois est que le travail de gestion de produit, qui consiste à obtenir des retours utilisateurs pour décider des fonctionnalités à construire, devient de plus en plus un goulot d'étranglement. L'année dernière, j'ai vu cette dynamique dans plusieurs équipes. Beaucoup commençaient à se plaindre de goulots d'étranglement en gestion de produit et en design car l'ingénierie était trop rapide. Il y a quelques années, la règle d'or dans la Silicon Valley était de quatre PM pour 100 ingénieurs, ou typiquement un PM pour six ou sept ingénieurs. À mesure que les ingénieurs accélèrent, nous voyons la vitesse de conception de la gestion de produit croître au même rythme. Je vois ces ratios changer. Hier encore, une de mes équipes m'a proposé non pas un PM pour quatre ingénieurs, mais un PM pour 0,5 ingénieur. C'est la première fois de ma vie que je vois un manager proposer d'avoir deux fois plus de PM que d'ingénieurs. C'est une dynamique très intéressante. Je ne sais pas si cette proposition est une bonne idée, mais c'est un signe de la direction que prend le monde. Je constate que les chefs de projet capables de coder ou les ingénieurs ayant une intuition produit ont tendance à mieux réussir. Une autre chose importante pour les leaders de start-ups est la vitesse à laquelle la technologie évolue. Si vous avez une bonne stratégie pour obtenir des retours rapides afin de façonner votre vision et décider plus vite quoi construire, cela vous aidera. Je vais donc présenter une série de stratégies pour obtenir des retours produits. Nous listerons des stratégies rapides mais potentiellement moins précises, et des stratégies plus lentes mais plus précises. La plus rapide est de regarder le produit soi-même et de juger à l'intuition. Si vous êtes expert d'un sujet, cela vous donne une efficacité inattendue. Un peu plus lent : demander à trois amis ou collègues de tester le produit. Encore plus lent : demander des retours à 3 ou 10 inconnus. J'ai appris que l'une des compétences les plus importantes est de savoir s'asseoir dans un café ou un hall d'hôtel, de repérer les endroits passants et d'aborder poliment des inconnus pour leur demander leur avis sur ce que je construis. C'est un peu gênant quand on vous reconnaît, mais avec mon équipe, nous regardons le flux de personnes et demandons poliment : 'Hé, on travaille sur ce truc, vous voudriez bien y jeter un œil ?'. J'ai appris que dans les cafés, beaucoup de gens travaillent et cherchent une excuse pour être distraits, ils sont ravis de le faire. J'ai pris énormément de décisions produit dans des halls d'hôtels ou des cafés. Envoyer des prototypes à 100 testeurs ou à plus d'utilisateurs sont des stratégies de plus en plus lentes. La Silicon Valley adore les tests A/B, j'en ai fait beaucoup. Mais le test A/B est maintenant l'un des plus lents de mon menu car sa mise en œuvre est lente et dépend du nombre d'utilisateurs. Une autre chose est que lorsque l'équipe décide en fonction des données, je n'utilise pas seulement les résultats des tests A/B pour choisir une option. Mon équipe s'assoit souvent pour examiner les données afin d'affiner notre intuition. Je souhaite que nous puissions utiliser la première stratégie pour prendre des décisions de haute qualité. S'asseoir souvent et se dire 'sur ce nom de produit, le modèle mental de l'utilisateur est erroné', et utiliser toutes ces données pour mettre à jour notre modèle de pensée afin d'améliorer notre intuition sur la manière de prendre des décisions produit plus rapidement est très important.

Nous avons parlé d'idées concrètes, de l'accélération de l'ingénierie et des retours produits. Voici une dernière chose que je souhaite aborder. J'ai découvert que comprendre l'IA permet réellement de progresser plus vite. En tant que praticien de l'IA, je la soutiens énormément et je partage avec vous pourquoi. Il s'avère qu'avec des technologies matures comme le mobile, nous savons déjà ce que les applications mobiles peuvent faire. Beaucoup de gens, y compris les non-techniciens, comprennent les fonctionnalités des applications. Si vous regardez les rôles en vente, marketing, RH ou juridique, ils sont très importants et difficiles, mais beaucoup de gens y excellent. Ces connaissances sont relativement dispersées car la manière de faire des RH n'a pas radicalement changé ces six derniers mois. Mais l'IA est une technologie émergente, et le savoir-faire en IA n'est pas généralisé. Les équipes qui comprennent vraiment l'IA ont donc un avantage sur celles qui ne la comprennent pas. Pour un problème RH, vous trouverez des experts. Mais pour un problème d'IA, savoir comment faire peut vous donner de l'avance. Par exemple, si un chatbot n'est pas assez précis, faut-il faire du fine-tuning ou optimiser le flux de travail ? Comment obtenir une faible latence pour la voix ? Avec la bonne décision technique, vous réglez le problème en quelques jours ; avec une mauvaise, vous risquez de vous perdre dans une impasse pendant trois mois. Une chose m'a surpris : si vous avez deux architectures possibles et que vous ne connaissez pas la réponse, essayer au hasard ne vous ralentit pas seulement de moitié. En pratique, si vous faites une erreur, vous ne mettez pas deux fois plus de temps, mais 10 fois plus à poursuivre une impasse. C'est pourquoi je pense qu'un bon jugement technique permet aux start-ups d'aller plus vite. Un autre domaine où maîtriser l'IA aide énormément est l'abondance d'outils GenAI incroyables apparus ces deux dernières années : flux de travail d'invites, garde-fous d'évaluation, comportement vocal, programmation asynchrone, extraction de données, embeddings, bases de données vectorielles, fine-tuning, bases de données de graphes. C'est une longue liste de blocs de construction que l'on peut assembler rapidement pour créer des logiciels inédits. Cela crée beaucoup d'opportunités. Quand je découvre ces blocs, voici l'image que j'ai en tête : avec un bloc blanc basique, vous construisez quelque chose de cool. Si vous savez comment faire des invites, vous avez un autre bloc. Avec un deuxième bloc pour construire des chatbots, vous faites des choses plus intéressantes. Avec des blocs rouges et jaunes, vos créations croissent de manière géométrique ou exponentielle. Comprendre tous ces blocs permet de les combiner dans des applications plus riches. Je suis moi-même beaucoup de cours sur le deep learning car nous collaborons avec DeepLearning.AI et presque toutes les grandes entreprises d'IA mondiales pour distribuer ces blocs de construction de manière certifiée. Chaque fois que j'apprends ces blocs fondamentaux via un cours, j'ai l'impression d'acquérir de nouveaux éléments combinables en de nouvelles applications logicielles impossibles il y a un ou deux ans. Pour conclure, voici mon résumé final. Beaucoup de choses sont importantes pour une start-up, pas seulement la vitesse. Mais quand j'observe les start-ups d'IA déjà en place, je constate que la capacité d'exécution rapide de l'équipe est fortement corrélée à ses chances de succès. Ce que nous avons appris pour gagner en vitesse, c'est de travailler sur des idées concrètes, et il faut qu'elles soient bonnes. En tant que cadre, on m'évalue sur la vitesse et la qualité de mes décisions ; les deux comptent, mais la vitesse est primordiale. L'ingénierie rapide assistée par l'IA permet d'aller plus vite, mais déplace le goulot d'étranglement vers l'obtention de retours utilisateurs, d'où la nécessité de stratégies pour obtenir des retours rapides. Si vous n'avez pas encore appris à aller dans un café pour parler à des inconnus, ce n'est pas facile, mais soyez simplement respectueux. C'est une compétence très importante pour un entrepreneur. Maîtriser la technologie augmente la vitesse. Merci beaucoup.