Les réunions enregistrées sont une ressource de connaissances sous-utilisée. Elles sont difficiles à parcourir, longues à réécouter et cloisonnées dans les lecteurs d’équipe, si bien que de précieux renseignements passent souvent inaperçus.
Lors d’un marathon de programmation d’une journée, une équipe de trois personnes a créé Callombia. Cette plateforme interne transcrit, étiquette et résume automatiquement les appels enregistrés, puis les découpe en extraits dans un dépôt consultable de type YouTube, accessible à tous les bureaux dans le monde.
Entièrement conçue avec Codex, la solution utilise une recherche sémantique alimentée par les plongements d’OpenAI et la similarité cosinus pour faire ressortir les passages pertinents, même sans mots-clés exacts, avec en complément un robot conversationnel RAG et un système de notifications.
Ce qui aurait autrefois pris des semaines a été réalisé en sept heures, montrant comment le développement axé sur l’IA avec des agents de programmation comme Codex peut considérablement raccourcir le cycle de développement des produits et tirer une réelle valeur commerciale des marathons de programmation internes.
Si vous êtes comme moi, vous avez rarement le temps — ou la capacité d’attention — nécessaire pour réécouter des réunions enregistrées. C’est souvent parce qu’il faut fouiller des lecteurs d’équipe désorganisés, passer les conversations banales de piètre qualité et essayer d’écouter vraiment tout en envoyant des courriels et des messages.
Mais peut-être que les choses pourraient être différentes? Pourrions-nous créer quelque chose qui transforme complètement les réunions enregistrées? C’est cette réflexion qui a inspiré notre récent projet de marathon de programmation.
En une seule journée, 50 membres de nos équipes d’ingénierie, de livraison et d’exploitation se sont attaqués à plusieurs problèmes provenant de toute l’entreprise : mise à l’échelle des opérations d’embauche, simplification de la création des énoncés des travaux, compréhension de la santé des projets, génération de prototypes en direct et extraction de renseignements des réunions enregistrées.
Lors de ce marathon de programmation fondé sur Codex, nous avons créé Callombia. Callombia est le YouTube de notre entreprise : il transforme chaque appel en une ressource vivante et consultable. Chaque appel est automatiquement transcrit, étiqueté et résumé, puis découpé en extraits thématiques et ajouté à un dépôt organisé par canal — les clients — et par sujet — les domaines d’expertise en IA. Ainsi, tout membre de l’équipe à Londres, Édimbourg, Singapour ou en Australie peut accéder instantanément aux passages d’appels qui l’intéressent.
Une interface familière et conforme à notre image de marque rend la découverte de contenu intuitive, tandis qu’une recherche sémantique — et bien sûr un robot conversationnel RAG fondé sur l’IA — aide chacun à trouver précisément ce qu’il cherche. L’ajout d’un système de notifications permet aussi à nos collègues de s’abonner à certains sujets et d’être avisés de la publication de nouveaux extraits pertinents.
Mais ce qui est génial avec Callombia, ce n’est ni le produit ni le prix de 2 000 £ remporté au marathon de programmation — petite vantardise —, mais le fait que deux ingénieurs et un responsable de la livraison aient pu tout créer en seulement sept heures. Cela n’aurait pas été possible il y a un an. Les progrès des agents de programmation ont considérablement accéléré le processus complet de développement des produits, et ce marathon de programmation a constitué un excellent terrain d’essai pour en comprendre les limites irrégulières. Alors, comment avons-nous utilisé Codex?
Plutôt que de simplement rédiger une foule d’exigences, nous avons d’abord présenté notre vision collective — sous forme d’invite — du problème et de l’orientation de Callombia. En restant volontairement vagues, nous avons laissé le modèle travailler et réfléchir de façon créative :
Après dix minutes d’échanges, nous avons activé le mode Plan pour préciser les exigences et orienter la partie technique de la conception. Le mode Plan donne l’impression de répondre aux questions de cet ami agaçant qui a — fort utilement — envisagé tous les scénarios possibles. Après nous être entendus sur des éléments comme le nombre de vidéos, le choix entre recherche sémantique et recherche par mots-clés, ainsi que l’architecture à utiliser, il a créé un fichier Markdown qui a ensuite servi de base au projet.
Une fois notre plan établi, l’étape suivante consistait à créer les composants principaux qui feraient réellement fonctionner Callombia. Il fallait donc créer un pipeline transformant les appels enregistrés en ressources consultables :
Ingérer les vidéos et les transcriptions;
Les découper en passages significatifs;
Les enrichir de résumés et d’étiquettes;
Les rendre accessibles par des API utilisables par l’application frontale.
Ed s’est surtout consacré à rendre les enregistrements bruts et les transcriptions exploitables, tandis que Nico s’est concentré sur la couche de récupération qui permettrait de découvrir ces passages. Grâce à Codex, ils ont tous deux pu mettre en place les modèles de données, les scripts d’extraction et l’infrastructure d’arrière-plan bien plus rapidement que nous aurions pu le faire manuellement. Nous avons ainsi obtenu bien plus qu’une transcription jointe à une vidéo. Nous avons obtenu des passages précis : la section sur Tesco, la mise à jour stratégique, la discussion sur l’embauche ou les 90 secondes précises d’un appel que quelqu’un souhaite réellement regarder.
C’est dans cette couche de récupération que les choses sont devenues particulièrement intéressantes. Nous voulions que quelqu’un puisse saisir une expression comme « rendement financier », « feuille de route de Tesco » ou « évaluations des conversations » et accéder aux extraits les plus pertinents, même si ces mots précis n’avaient jamais été prononcés. Pour y parvenir, nous avons créé des segments comprenant des horodatages, des résumés, le texte des transcriptions et des métadonnées. Avec une architecture claire en tête et beaucoup d’aide de Codex, nous avons réuni le sujet, le résumé et la transcription en une seule entrée, puis utilisé le modèle text-embedding-3-small d’OpenAI pour générer les plongements de chaque segment. Nous avons stocké ces plongements dans notre base de données et utilisé la similarité cosinus pour comparer la requête d’un utilisateur à chaque segment, créant ainsi une couche de récupération sémantique plutôt qu’une simple recherche par mots-clés.
Cette approche s’est révélée extrêmement précise et a donné au produit son côté « magique » pendant la démonstration du marathon de programmation. Nous savions toutefois que cette approche ne pourrait pas évoluer indéfiniment si le nombre de vidéos continuait de croître, car comparer chaque requête à chaque segment finirait par coûter trop cher. L’étape suivante naturelle consisterait à adopter des stratégies de récupération plus efficaces, comme Hierarchical Navigable Small World, afin de réduire le nombre de comparaisons et de maintenir une faible latence à mesure que le corpus s’agrandit. Une fois cette fonctionnalité opérationnelle, Callombia ressemblait moins à une médiathèque et davantage à un système de connaissances.
Comme dans tout bon marathon de programmation, cette partie a aussi dû être peaufinée : les limites initiales des segments étaient trop approximatives, certains horodatages devaient être resserrés, certaines étiquettes étaient trop générales et les fichiers de transcription ne correspondaient pas toujours parfaitement aux enregistrements. Mais c’est aussi là que la valeur est apparue. Codex nous a permis de perfectionner rapidement le système plutôt que de rester coincés dans la configuration et les reprises. À la fin, nous avions un arrière-plan capable d’alimenter des extraits, de courts passages et une recherche sémantique réellement utile. C’est alors que Callombia a commencé à ressembler à un véritable produit plutôt qu’à une simple démonstration de marathon de programmation.
Pendant qu’Ed et Nico créaient l’ingestion et la couche d’intelligence, je développais l’application frontale. Grâce à notre modèle de développement à pile complète, j’ai pu lancer rapidement une première version du site Web sans écrire une seule ligne de code. Après lui avoir demandé d’ouvrir le site Web localement dans mon navigateur, je fournissais de simples commentaires sous forme de puces pour faire évoluer la conception vers le résultat souhaité.
Après environ une heure d’échanges, j’avais obtenu un résultat dont j’étais plutôt satisfait, sans aucune expérience en interface utilisateur ou en conception. Même si le produit final est loin d’être parfait, c’est une très bonne première version qui permet aux gens de comprendre le produit.
Pour être certains d’avoir quelque chose à la fin de la journée, nous nous étions réparti le travail. Évidemment, après quelques heures de travail plutôt autonome, nous avions tous nos propres branches locales, avec une tonne de conflits.
Plutôt que de prendre le temps — que nous n’avions pas — d’examiner et de résoudre soigneusement les conflits, nous avons décidé de laisser Codex s’occuper librement des dépôts et tout régler seul. Même si nous ne recommanderions pas encore cette méthode pour le développement de logiciels d’entreprise, son efficacité dans un contexte à faible risque est incroyable et nous a fait gagner de nombreuses heures.
La dernière étape du marathon de programmation consistait à enregistrer la démonstration de Callombia pour les juges. Même si notre premier réflexe était d’ouvrir Loom pour effectuer l’enregistrement, nous avons pensé que ce serait un véritable test pour Codex, un peu au-delà de ses capacités actuelles. Alors… nous avons rédigé une invite, fourni un lien vers le site Web de Callombia, joint un enregistrement de ma voix sur la plateforme de développement d’OpenAI et demandé à Codex de faire le reste.
Le premier essai était très impressionnant : Codex avait rédigé un scénario de démonstration, enregistré l’écran, ajouté ma voix hors champ et essentiellement respecté les consignes. Le seul point qui ne nous satisfaisait pas immédiatement était la synchronisation de la voix avec l’enregistrement. Nous lui avons donc demandé : « OBLIGATOIRE : synchroniser exactement la voix hors champ avec ce qui est montré dans la démonstration. Il y avait un décalage, par exemple sur la page de clavardage. À la fin, vérifier trois fois la synchronisation de la voix et de la démonstration enregistrée à l’écran. Les faire correspondre par tous les moyens possibles. »
En réponse, Codex a divisé la voix hors champ et l’enregistrement en sections plus courtes, exécutant la tâche presque à la perfection juste à temps pour 17 h 30 et la bière-pizza de célébration.
Nous savons que Callombia résout un problème auquel la plupart des entreprises sont confrontées. Il est difficile d’assister à chaque appel dans une entreprise en croissance rapide, mais les perles de sagesse qui y sont partagées sont inestimables. Il ne nous reste plus qu’à le mettre en production.
Mais il y a ici une leçon plus générale sur l’adoption de l’IA et les avantages de consacrer le savoir-faire en ingénierie et en produit à la résolution de problèmes communs. En sortant de notre cycle de travail habituel et en collaborant entre équipes dans un environnement semi-concurrentiel, nous avons obtenu plusieurs solutions qui pourraient être mises en production moyennant quelques ajustements. En répétant régulièrement l’exercice, nous pouvons veiller à ce que nos processus internes soient aussi efficaces que les solutions conçues pour nos clients.