Georgia Tech AI Hackathon : Build Reality de 3 heures
J'ai regardé un extrait d'un hackathon du samedi à Georgia Tech cette semaine et il est resté dans ma tête pendant deux jours. Non pas à cause de l’énergie qui régnait dans la pièce – même s’il y en avait beaucoup – mais à cause d’un moment précis. Une caméra a filmé une équipe dans les vingt dernières minutes. Trois étudiants se penchaient autour d’un seul ordinateur portable. Leur application fonctionnait presque. Presque. Le genre de "presque" où le AI avait tout échafaudé au cours de la première heure, et ils avaient passé les deux heures restantes à essayer de l'empêcher de s'écraser lorsqu'un véritable humain le poussait.
Ce regard sur leurs visages est la chose la plus honnête que j'ai vue filmer sur le développement assisté par AI cette année.
L'événement était le hackathon Claude Builder Club, organisé sur le campus de Georgia Tech et sponsorisé par Anthropic. Le défi était de taille : créer une application mobile ou Web qui aide les gens à maintenir des habitudes saines à l'aide d'une conception basée sur AI. Trois heures. Invite révélée au début. Equipe jusqu'à trois personnes. Ordinateurs portables fermés au buzzer, puis présentations à un jury. L'équipe gagnante a créé une application gamifiée de suivi des repas qui suggérait des associations nutritionnelles et récompensait les utilisateurs pour leurs séquences saines.
C'est l'histoire superficielle. L'histoire ci-dessous – celle que je continue de parcourir – est ce que ces trois heures révèlent sur le fonctionnement réel du logiciel d'expédition lorsque AI effectue la saisie.
Parce que voici ce que personne ne vous dit lorsque vous regardez une démo de Claude sur Twitter et voyez une application complète tourner en six minutes : la démo est la partie la plus facile. Le plus difficile, c'est tout entre "le prototype est superbe" et "un vrai humain peut lui faire confiance avec quelque chose qui compte". Un hackathon est un microcosme parfait de cet écart, et les étudiants de Georgia Tech l'ont vécu devant la caméra en trois heures.
Reste avec moi. La raison pour laquelle c'est important n'est pas le hackathon. C'est ce que le hackathon prouve au cours des douze prochains mois pour chaque produit construit par AI et arrivant sur l'App Store.
À quoi ressemble réellement un hackathon AI de trois heures
Permettez-moi de planter le décor avec les chiffres, car le cadrage compte.
Le College of Computing de Georgia Tech a inscrit 4 621 étudiants de premier cycle et 16 910 étudiants des cycles supérieurs en informatique au cycle d'automne 2024, ce qui en fait l'un des plus grands programmes informatiques du pays. L'informatique est la spécialité la plus populaire sur le campus. Lorsque le Claude Builder Club d'Anthropic y organise un événement, le plancher de talents est élevé : il ne s'agit pas d'étudiants d'introduction à l'informatique qui rencontrent leur premier API. Beaucoup d'entre eux ont livré de vrais projets, contribué à l'open source et ont déjà utilisé Claude Code ou le SDK Anthropic dans leur pile personnelle.
Maintenant, déposez-les dans un conteneur de trois heures avec une nouvelle invite et dites-leur de créer une application de santé fonctionnelle avec AI comme auteur principal. Ce qui se produit?
Ce qui se passe est exactement ce qui s'est passé dans la vidéo : un échafaudage rapide, puis une lente et frustrante rampe vers quelque chose qui ne s'effondre pas au premier contact avec la réalité.
Les trente premières minutes sont généralement les plus magiques. Une équipe choisit un angle – suivi des repas, hydratation, sommeil, peu importe – et commence à proposer des suggestions. Claude Opus 4.7 (publié le 16 avril 2026, le modèle Anthropic le plus performant lors du déroulement de ce hackathon) peut échafauder une application native Next.js ou React complète avec authentification, hooks de base de données et un UI fonctionnel dans une seule conversation. Je l'ai fait moi-même pour des projets personnels. Vous regardez l'arborescence des fichiers se remplir, les composants se composer, le serveur de développement démarrer et vous ressentez quelque chose de proche du vertige. Nous avons déjà terminé à 60 %. Il nous reste deux heures et demie. Cela va être facile.
Ensuite, vous ouvrez l'application et appuyez sur le premier bouton.
C’est là que commence le hackathon de chaque équipe.
L'écart entre l'échafaudage et le navire est l'endroit où vivent les ingénieurs
Quand je pense à la façon dont j'utilise AI dans mon propre travail, cet écart correspond à 90 % de mon temps - et je pense que c'est la partie que la plupart des gens sous-estiment lorsqu'ils prédisent ce que AI fera aux tâches logicielles.
Voici un exemple concret de ma propre semaine. Je construisais un petit outil interne – un ingesteur CSV qui se connecte à un flux de travail de balisage. Claude Code 2.1 a échafaudé l'ensemble du projet en six minutes environ. Structure des dossiers, logique de l'analyseur, appareils de test, une interface CLI propre. La première exécution a fonctionné sur les données de test que j'avais fournies à Claude. La deuxième exécution, sur un vrai CSV provenant d'un client, s'est interrompue à trois endroits : un caractère de nomenclature parasite au début du fichier, une colonne avec des encodages mixtes et une ligne d'en-tête qui comprenait une cellule d'espacement fantôme en raison de la façon dont l'exportation Excel d'origine l'avait écrit.
Aucun de ces bugs n'était présent dans l'invite. Aucun d'entre eux ne figure dans aucun didacticiel. Ils apparaissent parce que les données réelles sont désordonnées, que les vrais utilisateurs font des choses imprévisibles et que la seule façon de trouver ces modes de défaillance est de les confronter à la réalité.
Cet écart — entre « AI a échafaudé un prototype fonctionnel » et « cela peut survivre à de vrais utilisateurs » — est exactement l'écart qu'un hackathon vous fait vivre en temps réel. Les étudiants de Georgia Tech n'étaient pas en retard car Claude était lent. Ils étaient en retard car la recherche des dix-sept cas extrêmes qui cassent une véritable application de suivi des repas prend plus de trois heures, quelle que soit la vitesse de votre AI.
Le doyen associé du College of Computing de Georgia Tech l'a dit clairement dans la vidéo : les humains doivent rester « au courant » pour tester, affiner et garantir que les sorties générées par AI sont utilisables et dignes de confiance. Ce n'est pas une couverture polie. C'est la véritable description de poste des ingénieurs logiciels en 2026.
Pourquoi la compression du temps révèle ce que l'échelle cache
Il y a une raison pour laquelle un hackathon de trois heures est plus révélateur qu'un projet d'entreprise AI de trois mois.
Quand on dispose de trois mois et de douze ingénieurs, on peut masquer le manque. Vous pouvez avoir un ingénieur qui demande Claude toute la journée, deux autres cas de nettoyage, trois autres tests d'écriture et un concepteur peaufinant le UX. L'équipe livre une « application construite par Claude », mais en réalité, Claude a écrit la première ébauche et une petite armée d'humains l'a transformée en quelque chose de confiance pour les utilisateurs. L'histoire que vous racontez sur LinkedIn est la suivante : "nous l'avons construit avec AI". L'histoire racontée par votre journal git est plus honnête.
Compressez le même workflow en trois heures, avec trois personnes, et vous ne pourrez rien cacher. Soit le AI vous a amené à la ligne, soit ce n'est pas le cas. Soit vous avez trouvé les bugs, soit votre démo plante devant les juges.
C'est pourquoi les hackathons restent le test le plus clair de la manière dont AI modifie réellement le rythme de la construction. Les conférences industrielles et les vidéos de démonstration vous montrent toutes les moments magiques. Les hackathons vous montrent ce qui se passe entre les moments magiques – la séquence silencieuse de trente minutes où quelqu'un fouille dans une trace de pile parce que le AI a appelé en toute confiance une fonction qui n'existe pas dans la version du SDK qu'il utilise.
J'ai appris davantage sur mon propre flux de travail AI en réalisant des builds personnels de 24 heures qu'en n'importe quel article de blog. La discipline consistant à « expédier quelque chose qui fonctionne dans un délai fixe » vous oblige à déterminer quelles parties de votre pile vous font réellement gagner du temps et quelles parties sentent comme elles vous font gagner du temps.
Il y a ici un motif subtil que je continue de voir dans mon propre travail et que je vois clairement dans les images du hackathon. J'y reviendrai après avoir examiné pourquoi l'équipe gagnante a gagné.
Ce que l'application gagnante de suivi des repas a réussi
L'équipe qui a remporté la première place lors de ce hackathon Georgia Tech AI n'a pas construit la chose la plus impressionnante techniquement. Ils ont construit la bonne chose. Cette distinction est essentielle dans une construction limitée dans le temps.
Leur application combinait le suivi des repas et la gamification : des séquences pour une alimentation saine, des suggestions d'associations nutritionnelles (protéines avec glucides, ce genre de choses) et des récompenses pour la cohérence. Sur le papier, cela semble simple. Ci-dessous, vous trouverez un exemple classique de ce qui fonctionne actuellement dans les applications mHealth.
Les applications de régime et de nutrition ont un problème de rétention brutal. Les données du secteur montrent qu'environ 30 % des utilisateurs se désabonnent au cours du premier mois. Environ 70 % des utilisateurs abandonnent une application de nutrition dans les deux semaines si elle semble trop complexe ou prend beaucoup de temps. La journalisation des repas est l'un des comportements quotidiens les plus exigeants des utilisateurs dans les logiciels grand public, au même titre que la journalisation : elle demande à l'utilisateur d'effectuer un travail conscient avant d'être récompensé.
Mais voici le point de données qui fait cliquer le choix de l'équipe gagnante : les applications de santé gamifiées affichent un engagement et une rétention environ 50 % plus élevés que leurs équivalents non gamifiés. Les badges de réussite augmentent à eux seuls l’engagement d’environ 40 %. La mécanique des séquences – la même primitive qui alimente la rétention de MyFitnessPal – fonctionne parce qu'elle détourne l'aversion à la perte. Vous ne voulez pas briser la chaîne.
L'équipe gagnante n'a pas inventé la gamification pour les applications de nutrition. Ils ont choisi un modèle de rétention connu et ont laissé Claude échafauder l'implémentation autour de celui-ci. C'est le mouvement. Dans un conteneur de trois heures, l’équipe qui gagne n’est pas celle dont l’architecture est la plus novatrice. C'est l'équipe qui reconnaît quel modèle a déjà des preuves et utilise AI pour expédier ce modèle plus rapidement.
C’est exactement ainsi que je pense à mes propres builds maintenant. Je n'essaie pas d'inventer de nouvelles mécaniques. Je lis les données de conservation, identifie quels mécaniciens ont des preuves et utilise Claude pour les échafauder en un après-midi. La bande passante créative ne consiste pas à inventer de nouvelles roues, mais à choisir la roue qui compte et à la resserrer pour mon utilisateur spécifique.
Les cinq modes d'échec du Hackathon que je vois à plusieurs reprises
Si vous regardez suffisamment de hackathons – ou exécutez suffisamment de builds personnels de trois heures – les mêmes cinq modes d’échec se répètent. La séquence Georgia Tech en montre au moins trois. Les voici, dans l'ordre dans lequel ils ont tendance à mordre.
Mode d'échec un : dérive de la portée dans les trente premières minutes. Une équipe reçoit l'invite et commence à riffer. Ils passent du « suivi des repas » au « suivi des repas plus flux social plus nutritionniste AI plus scanner de codes-barres ». Le AI est si disposé que l'équipe confond « Claude peut échafauder ceci » avec « nous pouvons expédier ceci ». Deux heures plus tard, ils disposent de six fonctionnalités à moitié construites et de aucun flux de travail. Le remède est brutal : choisissez un utilisateur, un écran, une interaction, et envoyez-le. N'ajoutez rien jusqu'à ce que le noyau fonctionne.
Mode d'échec deux : faire confiance au premier UI généré par AI. La sortie native React ou React par défaut de Claude est compétente mais générique. Le premier écran de héros a toujours les mêmes dégradés violets, les mêmes icônes génériques, la même copie CTA. Les équipes qui livrent quelque chose de mémorable passent au moins 20 minutes à peaufiner manuellement l'identité visuelle, non pas parce que le résultat du AI est mauvais, mais parce que le AI de toutes les autres équipes produit un résultat similaire à partir d'invites similaires. Si vous avez lu mon analyse des pourquoi les sites Web générés par AI se ressemblent tous, il s'agit du même problème d'empreintes digitales appliqué aux applications.
Mode d'échec trois : zéro gestion des erreurs. Un chemin heureux et fonctionnel est une construction de 30 minutes. Une application fonctionnelle avec des erreurs gérées est une construction de trois jours. Les hackathons compressent cela brutalement. L'équipe qui gagne est généralement celle qui encapsule chaque appel API dans un try/catch, affiche des états vides gracieux et dispose d'au moins une solution de secours lorsque la fonctionnalité AI expire. Les démos ne plantent pas sur scène parce que l'équipe a eu de la chance - elles ne plantent pas parce que l'équipe a traité la gestion des erreurs comme une fonctionnalité de première classe, et non comme une étape de polissage.
Mode d'échec quatre : juger la sortie du AI en le lisant au lieu de l'exécuter. Je vois cela dans mon propre travail et je l'ai vu clairement dans les images du hackathon. Une équipe invite Claude, analyse le résultat, voit « ouais, ça a l'air bien » et passe à autre chose. Puis, à la minute 145 sur 180, ils exécutent le code et trois choses se cassent. La discipline qui sépare les expéditeurs rapides des expéditeurs lents est d'exécuter immédiatement chaque modification générée par AI. Lire-ne pas exécuter est le raccourci le plus coûteux dans le développement assisté par AI.
Mode d'échec cinq : oublier que la démo est le livrable. Un hackathon n'est pas une révision de code. Il s'agit d'un argumentaire de vente avec un logiciel en cours d'exécution en dessous. Les équipes qui construisent un parcours de démonstration propre de deux minutes (commencer à l'écran d'accueil, atteindre les trois moments impressionnants et terminer par une conclusion satisfaisante) battent les équipes avec des produits plus ambitieux qui ne savent pas comment montrer ce qu'elles ont construit. Il en va de même pour l’expédition de tout produit AI. Les 90 premières secondes de l'utilisateur constituent la démo. Concevez ces 90 secondes intentionnellement.
Si vous utilisez Claude Code pour créer quoi que ce soit dans un délai limité, ces cinq modes d'échec valent la peine d'être imprimés et épinglés sur votre moniteur.
La question de l'humain dans la boucle était déjà réglée – voici ce qui change réellement
La vidéo présentait la discussion humaine comme s’il s’agissait encore d’une question ouverte. AI remplacera-t-il les développeurs, ou les humains resteront-ils essentiels ? Je souhaite revenir sur ce cadrage car je pense que ce n'est pas la bonne question, et le hackathon lui-même l'a prouvé.
Cette question a été réglée au moment où Anthropic a livré Claude Code 2.0 et que les développeurs ont commencé à l'exécuter en tant que boucle d'agent avec des points de contrôle humains. La réponse est que les humains restent au courant. La question intéressante – celle qui change en réalité de mois en mois – est de savoir où appartiennent les points de contrôle humains.
En 2024, le point de contrôle humain dans la boucle se situait au niveau de la ligne. Vous demanderiez une fonction au AI et liriez chaque ligne avant de la coller. En 2025, le point de contrôle a été déplacé au niveau du fichier ou du module : Claude pouvait écrire un fichier entier et vous examineriez la différence. En avril 2026, avec l'Opus 4.7, le point de contrôle est passé au niveau fonctionnalité. Claude peut créer, tester et auto-corriger une fonctionnalité entière, et le réviseur humain vérifie le comportement de la fonctionnalité, pas ses lignes.
C’est ce que le doyen associé soulignait en réalité – et ce que le hackathon a démontré sous forme compressée. Les étudiants n'écrivaient pas chaque ligne. Ils exécutaient, testaient, incitaient et réincitaient jusqu'à ce que le comportement corresponde à ce qu'ils voulaient. Le rôle humain a atteint un niveau d'abstraction, mais il n'a pas disparu. Au contraire, cela est devenu plus difficile, car la révision du comportement demande plus de compétences que la révision de la syntaxe.
Soit dit en passant, c'est exactement pourquoi je continue de dire que « l'alphabétisation AI » est un mauvais cadre pour ce dont les étudiants ont besoin actuellement. L'alphabétisation AI implique des compétences en lecture. Ce dont vous avez réellement besoin, c'est d'un jugement AI : savoir quand faire confiance à la sortie, quand ré-inviter, quand la jeter et l'écrire vous-même, et quand le AI est faux en toute confiance. C'est un métier, pas une alphabétisation. Et comme tout métier, il ne se développe qu’en construisant des choses qui doivent réellement fonctionner.
Un hackathon de trois heures dans une grande école d'informatique est l'un des terrains de formation les plus propres que je puisse imaginer pour le jugement AI. Vous ne pouvez pas faire semblant. Le buzzer s'en fiche.
Ce que je vole au Hackathon pour mes propres builds
Regarder cette vidéo a changé trois choses dans la façon dont j'exécute mes propres builds AI ce mois-ci. Non pas exactement parce que j'ai appris quelque chose de nouveau, mais parce que le hackathon a clarifié intuitivement les choses que je faisais.
Premièrement : je fixe des délais plus difficiles. J'avais l'habitude de me donner une semaine pour expédier un petit outil. Maintenant, je m'accorde une soirée. Non pas parce que je suis plus rapide (Claude est plus rapide, je ne le suis pas), mais parce que des délais plus courts obligent la discipline à ignorer des fonctionnalités qui n'ont pas d'importance. La contrainte de trois heures chez Georgia Tech n'était pas cruelle – elle était clarificatrice. La plupart de ce qui est coupé sous la pression des délais ne sera jamais expédié de toute façon.
Deux : je charge en premier le chemin de la démo. Avant d'écrire une ligne, j'écris la démo de deux minutes que je veux donner. Cliquez ici, voyez ceci, appuyez dessus, regardez l'incrément du compteur de séquences, voyez l'animation de récompense. Ensuite, je travaille à rebours et je construis uniquement ce qui est nécessaire pour que cette démo fonctionne. Tout le reste est un objectif ambitieux. Ce seul changement a à peu près doublé mon taux de réalisation de projets parallèles.
Trois : j'exécute immédiatement chaque modification de AI. J'avais l'habitude de lire la sortie de Claude, d'acquiescer et de passer à autre chose. Maintenant, je le lance. À chaque fois. Si Claude a ajouté une fonction, je l'appelle avec une entrée réelle. Si Claude a échafaudé un composant, je le restitue avec des données réelles. Le frottement est faible. Le taux de découverte de bogues est énorme. La plupart des échecs que je trouvais à la fin d'une construction, je les retrouve désormais dans les quatre-vingt-dix secondes suivant la modification.
Si vous utilisez Claude Code ou tout autre outil de codage agent avec désinvolture et que vous souhaitez passer au niveau supérieur, ces trois changements valent à eux seuls plus que n'importe quel modèle d'invite que j'ai partagé.
Le plafond n'est pas la capacité AI - c'est la confiance
Voici la partie du hackathon sur laquelle je reviens sans cesse. L’application gagnante de suivi des repas était intelligente. La présentation était serrée. Les juges ont adoré. Et il est presque certain qu’aucun de ces juges n’utiliserait cette application pour gérer son propre régime alimentaire.
Ce n’est pas un coup dur pour l’équipe – c’est actuellement le plafond fondamental des applications grand public construites par AI. La capacité n’est plus le goulot d’étranglement. Claude Opus 4.7 peut créer une application de santé entière en une heure avec une meilleure ergonomie par défaut que l'application médiane de l'App Store. Le goulot d'étranglement est la confiance. Les vrais utilisateurs transmettront-ils leurs données alimentaires, leurs données de sommeil, leurs données de santé à une application dont ils ne connaissent pas le créateur, dont ils n'ont pas lu la politique de confidentialité, dont ils ne peuvent pas vérifier le comportement de conservation des données ?
C’est précisément dans cet écart de confiance que réside la prochaine vague d’avantages concurrentiels. N’importe qui peut créer une application AI. Presque personne ne peut construire une infrastructure de confiance autour de cela : une gestion claire des données, un comportement prévisible dans les cas extrêmes, une accessibilité pour les utilisateurs qui ne correspondent pas au chemin du bonheur, des états d'erreur qui ne font pas que l'utilisateur se sente stupide et une marque qui signale "cela sera là dans dix-huit mois".
C’est également pourquoi la conversation entre humains est importante bien au-delà des hackathons. En 2026, la question n'est pas AI peut-il le construire. La question est est-ce qu'un humain l'a vérifié suffisamment bien pour que quelqu'un avec un skin dans le jeu l'utilise. Les flux de travail hybrides AI, où l'automatisation est associée à une surveillance humaine à la bonne altitude, constituent désormais la norme de production. Les observateurs de l'industrie ont commencé à appeler ce « AI vérifié par l'homme » comme différenciateur de marque. Ils n'ont pas tort. Le marché commence à évaluer la confiance de la même manière qu’il évaluait la qualité du code : en tant que fossé concurrentiel.
Les équipes de hackathon qui ont perdu n'ont pas été surclassées en termes de capacités. Ils ont été surclassés en termes de jugement : quelles fonctionnalités expédier, lesquelles couper, quel boîtier de pointe gérer, dans quel polissage investir. Ce jugement est la chose que AI ne remplace pas. C'est la chose que AI amplifie lorsque l'humain qui la manie l'a, et l'expose brutalement lorsque l'humain ne l'a pas.
Ce que faisaient réellement les trois étudiants à la minute 145
Permettez-moi de revenir sur ce moment de la vidéo qui me trotte dans la tête.
Trois étudiants. Un ordinateur portable. Il reste vingt minutes au compteur. Leur application fonctionnait presque. Ils étaient en train de déboguer, invitant Claude, réexécutant, invitant à nouveau. Essayer de mettre à jour le compteur de séquences sans planter la vue du tableau de bord.
Ce n'est pas une histoire de AI remplaçant les développeurs. C'est l'histoire de trois jeunes ingénieurs qui apprennent en temps réel le véritable travail d'un développeur de l'ère AI. Le travail n'est pas d'écrire du code. Le travail n'invite même pas AI. Le travail est la boucle : définissez le comportement souhaité, invitez le AI, exécutez le résultat, trouvez l'écart entre le comportement et la réalité, invitez à nouveau, exécutez à nouveau, jusqu'à ce que l'écart se comble. Cette boucle concerne désormais toute la profession.
Un hackathon de trois heures à Georgia Tech n'expose pas les étudiants à AI. Cela leur apprend la boucle. Cela vaut plus que n'importe quel cours sur l'ingénierie rapide ou n'importe quel tutoriel sur le SDK Anthropic. Vous apprenez la boucle en l'exécutant sous pression, pas en lisant.
Si je dirigeais un programme CS en 2026, je demanderais à chaque étudiant de participer au moins un hackathon solo de trois heures par mois. Non pas parce que les hackathons sont intrinsèquement géniaux – ils sont brutaux – mais parce que rien d’autre ne compresse toute la boucle de développement de l’ère AI en un seul après-midi comme ils le font.
Questions fréquemment posées
Quelle était l'invite du hackathon Georgia Tech AI ?
Le hackathon Claude Builder Club organisé à Georgia Tech a mis les étudiants au défi de créer une application mobile ou Web qui aide les gens à maintenir des habitudes saines à l'aide d'une conception basée sur AI, dans une fenêtre de trois heures. L'invite n'a été révélée qu'au début du concours et des équipes composées de trois étudiants maximum pouvaient concourir. La candidature gagnante était une application gamifiée de suivi des repas avec des récompenses de série et des suggestions d'associations nutritionnelles.
Quel modèle Claude a été utilisé lors du hackathon Georgia Tech sponsorisé par Anthropic ?
Les hackathons sponsorisés par Anthropic en 2026 donnent généralement aux participants accès aux derniers modèles Claude, notamment Claude Opus 4.7 (publié le 16 avril 2026) pour les tâches de codage complexes et Claude Sonnet 4.6 pour une itération plus rapide. La plupart des équipes utilisent Claude Code ou Anthropic API directement pendant la fenêtre de construction. Pour une description plus complète de la façon dont je les utilise en production, consultez mon guide de workflow Claude Code.
À quelle vitesse AI peut-il réellement créer une application fonctionnelle en 2026 ?
Claude Opus 4.7 peut créer une application native Next.js ou React complète (authentification, base de données, UI) en six à quinze minutes environ. L'« échafaudage » n'est pas la même chose que le « produit prêt à être expédié ». Les utilisateurs réels rencontrent des cas extrêmes, des états d'erreur et des formes de données que l'échafaudage ne gère pas par défaut, ce qui prend généralement la majeure partie du temps de construction, même avec l'assistance de AI.
Pourquoi la gamification fonctionne-t-elle si bien dans les applications de santé ?
La gamification fonctionne parce que les comportements liés à la santé nécessitent des frictions quotidiennes (enregistrement, suivi, choix) et que les récompenses d'un mode de vie sain mettent du temps à se matérialiser. Les séquences, les badges et les boucles de récompense compressent la chronologie des commentaires afin que les utilisateurs ressentent des progrès en quelques jours au lieu de plusieurs mois. Les applications de santé gamifiées affichent un engagement et une rétention environ 50 % plus élevés que leurs équivalents non gamifiés, les badges de réussite augmentant à eux seuls l'engagement d'environ 40 %.
Le modèle humain dans la boucle est-il toujours pertinent lorsque AI en est-il capable ?
Oui, plus, pas moins. À mesure que les capacités de AI se sont développées, le point de contrôle humain dans la boucle est passé de l'examen au niveau de la ligne à la vérification du comportement au niveau des fonctionnalités. Le consensus de l'industrie en 2026 considère le AI vérifié par l'homme comme la norme de production pour tout système où la confiance, la conformité ou la sécurité sont importantes. La question n’est pas de savoir si les humains restent dans la boucle, mais où ils se situent dans la boucle.
Le buzzer ne ment pas
La raison pour laquelle la vidéo Georgia Tech est restée dans ma tête pendant deux jours n'est pas liée à la technologie. C'est ce que le buzzer a révélé.
Trois heures. Les meilleurs modèles d'Anthropic. Certains des étudiants en informatique les plus talentueux du pays. Et l'écart entre « AI peut le construire » et « les utilisateurs peuvent lui faire confiance » était encore plus large que trois heures ne pourraient le combler. Cet écart représente tout le travail désormais. C’est dans cet écart que chaque ingénieur, chaque fondateur, chaque constructeur solo va passer les cinq prochaines années de sa carrière.
Ce soir, avant de vous coucher, offrez-vous une box de trois heures. Choisissez quelque chose de petit. Ouvrez Claude Code. Réglez une minuterie. Voyez ce que vous pouvez expédier entre l’échafaudage et la confiance. Vous en apprendrez davantage sur la façon dont AI change réellement le rythme de la construction que vous ne le feriez lors de n'importe quelle conférence de cette année.
Le buzzer ne ment pas. La démo non plus.
Travaillons ensemble
Vous cherchez à créer des systèmes AI, à automatiser les flux de travail ou à faire évoluer votre infrastructure technologique ? J'aimerais aider.
- Fiverr (versions et intégrations personnalisées) : fiverr.com/s/EgxYmWD
- Portefeuille : mejba.me
- Ramlit Limited (solutions d'entreprise) : ramlit.com
- ColorPark (conception et image de marque) : colorpark.io
- xCyberSecurity (services de sécurité) : xcybersecurity.io
