Comment Alan a permis à ses designers et à ses PMs de livrer du code en production grâce à l'IA

Alan a été lancée en 2016 avec une mission : rendre la santé plus proactive, plus transparente et plus simple à utiliser. Au fil des années, la boîte est allée au-delà de l'assurance pour devenir une plateforme de santé plus large, centrée sur la prévention et le soin au quotidien.

Aujourd'hui, la boîte génère plus de 785 M€ de revenus annuels, compte plus de 1 million de membres, travaille avec plus de 35 000 entreprises et organisations publiques et emploie près de 800 personnes dans quatre pays. La semaine dernière, Alan a annoncé une levée de 480 M€ en série G, qui porte sa valorisation à 5,5 Md€. Menée par Prosus, cette levée va accélérer l'expansion internationale de la boîte, renforcer ses investissements dans l'IA et soutenir son ambition : faire de la prévention, et non du traitement, le standard mondial de la santé

Alexandre Gerlic a rejoint Alan en 2019, quand l'équipe engineering comptait environ 20 personnes. Depuis, il l'a aidée à passer à plus de 100 ingénieurs, tout en gardant une forte culture d'ownership distribué et d'autonomie.

J'ai échangé avec Alexandre Gerlic, VP Engineering chez Alan, pour parler de la façon dont l'IA a transformé la manière dont Alan construit ses produits, de la façon dont les non-ingénieurs contribuent maintenant directement aux systèmes de production, et de ce que ça change pour les organisations produit à grande échelle.

Disclaimer : les choix d'organisation et les solutions techniques partagés dans cette newsletter ne sont pas faits pour être copiés-collés tels quels. Garde toujours en tête le contexte de ta boîte avant d'adopter quelque chose qui marche ailleurs ! 😊

‍

Former des champions IA en interne avant de passer à l'échelle

Alan a commencé à travailler sérieusement sur l'IA avant que ChatGPT ne devienne grand public. La première impulsion est venue directement des fondateurs, convaincus que l'IA allait transformer chaque fonction de la boîte.

Alan a repéré les salariés qui expérimentaient déjà des outils d'IA dans leur travail quotidien et les a encouragés à porter l'adoption au sein de leurs équipes. Ces personnes sont progressivement devenues des « champions » internes dans toute l'organisation.

La boîte leur a ensuite donné du temps, des accès et des moyens pour tester des workflows propres à leur domaine :

• les équipes sales ont exploré des workflows de vente
• les designers ont exploré des workflows créatifs
• les équipes produit ont exploré le prototypage
• les ingénieurs ont exploré les assistants de code

Ça a permis à l'adoption de l'IA de se diffuser naturellement, par l'apprentissage entre pairs.

L'un des premiers exemples était étonnamment simple. Alan a créé un bot Slack capable de générer instantanément de nouvelles versions de sa mascotte, la marmotte. Les salariés pouvaient demander des variantes directement dans Slack et voir le résultat tout de suite.

L'expérience semblait ludique au départ, mais elle a aidé les équipes à comprendre à quel point l'itération pouvait devenir rapide avec les outils d'IA.

« On avait 800 personnes qui utilisaient l'IA tous les jours, dans toutes les fonctions », Alexandre Gerlic

Cette première phase a créé un changement d'état d'esprit important. Les équipes ont commencé à se demander comment l'IA pouvait améliorer leurs propres workflows, au lieu d'attendre un plan de transformation officiel.

‍

Donner à chaque équipe accès au même environnement de développement

L'une des décisions les plus importantes d'Alan a été de donner aux non-ingénieurs accès au même environnement de développement que les ingénieurs.

La boîte a d'abord testé cette approche avec les équipes opérations qui travaillaient sur des outils internes. Les salariés voulaient corriger de petites frictions dans leurs workflows, qui passaient rarement dans les priorités de l'engineering, comme changer l'ordre d'un menu déroulant ou corriger des problèmes d'UI récurrents.

Alan a ensuite créé une initiative appelée « Everyone Can Build ».

La boîte a étendu son environnement et ses workflows engineering existants aux équipes business, pour que tout le monde puisse collaborer dans le même système :

• même codebase
• même setup de développement
• même process de review
• mêmes standards de déploiement
• mêmes systèmes qualité

Ça a créé un modèle de fonctionnement commun entre l'engineering, le produit et le design.

L'objectif était aussi de garder des boucles de collaboration courtes. Les améliorations faites pour les ingénieurs pouvaient profiter immédiatement aux designers et aux PMs, et inversement.

« Le choix contre-intuitif qu'on a fait, c'est de décider de ne pas utiliser de nouveaux outils », Alexandre Gerlic

Le déploiement s'est fait progressivement. Les designers ont adopté le workflow en premier, puis ont commencé à aider d'autres designers à prendre le système en main. Plus tard, les PMs et d'autres équipes ont aussi commencé à contribuer directement.

Avec le temps, les discussions produit sont devenues plus tournées vers l'exécution. Au lieu d'ouvrir un ticket pour chaque idée, les équipes pouvaient prototyper et tester des améliorations directement dans l'environnement du produit.

‍

Poser des garde-fous solides pour que les non-ingénieurs livrent en toute sécurité

Ouvrir les workflows de production aux non-ingénieurs demandait une couche d'infrastructure solide en dessous.

Alan a d'abord limité les contributions aux changements frontend. Ça réduisait le risque opérationnel, tout en permettant aux équipes de travailler sur des améliorations produit visibles.

La boîte a ensuite réutilisé tous les garde-fous engineering existants :

• linters
• systèmes de validation du code
• contrôles de déploiement
• code reviews
• environnements de développement

Ces garde-fous sont devenus essentiels pour faire passer l'initiative à l'échelle en toute sécurité.

Alan a fortement personnalisé son environnement Cursor pour accompagner les non-ingénieurs. Un ajout important : un assistant capable d'estimer la complexité d'implémentation. Ça aidait les designers et les PMs à comprendre si un changement demandé était simple ou s'il demandait un vrai travail d'engineering.

La boîte a aussi optimisé les boucles de feedback. Les équipes pouvaient modifier des éléments d'interface en langage naturel et voir instantanément l'impact dans l'application.

Ça a rendu l'expérimentation beaucoup plus accessible aux non-ingénieurs.

« Quand les gens ont compris qu'ils pouvaient modifier les outils qu'ils utilisent tous les jours, ils avaient des étoiles dans les yeux », Alexandre Gerlic

Un résultat intéressant : les pull requests générées par l'IA amélioraient parfois les systèmes existants automatiquement. Dans un exemple, la migration d'un outil interne vers le nouveau design system d'Alan s'est faite pendant une simple modification d'interface.

‍

Faire passer les discussions produit des contraintes de capacité à l'ambition

À mesure que les coûts d'implémentation baissaient, Alan a remarqué un changement dans la façon dont les équipes parlaient de priorisation.

Avant, beaucoup de décisions produit dépendaient fortement de la bande passante de l'engineering. Certaines améliorations restaient en basse priorité parce que l'effort d'implémentation semblait trop élevé par rapport à l'impact.

L'IA a changé cette équation.

Les petits bugs et les frictions de workflow sont devenus plus faciles à traiter rapidement. Les équipes pouvaient tester des idées plus vite et passer du concept à l'implémentation avec moins de coordination.

Ça a progressivement changé la nature des discussions produit.

Les équipes ont commencé à se demander moins si elles pouvaient construire quelque chose, et plus où elles voulaient mettre leur ambition et leur focus.

L'impact s'est aussi vu dans la structure des équipes. Alan a toujours préféré les petites équipes autonomes. Avec les workflows assistés par l'IA, la boîte explore maintenant l'idée que certaines initiatives puissent démarrer avec seulement deux personnes.

Ça touche :

• la vitesse d'expérimentation
• les coûts de coordination
• les modèles d'ownership
• la composition des équipes
• la flexibilité de la roadmap

En même temps, de nouvelles contraintes sont apparues ailleurs dans le workflow :

• la code review
• la validation
• les tests
• la vitesse de déploiement
• la cohérence du produit

Alexandre explique qu'accélérer une partie du cycle de développement produit augmente naturellement la pression sur les étapes suivantes.

Alan explore maintenant des workflows où l'IA accompagne non seulement la génération de code, mais aussi les process de validation et de review.

‍

Transformer le savoir opérationnel en skills IA réutilisables

À mesure que les modèles d'IA progressaient, Alan a déplacé son attention de la pure génération de code vers des workflows d'organisation réutilisables.

La boîte a commencé à construire des « skills » capables d'encoder le savoir et les process internes :

• standards de reporting
• workflows opérationnels
• conventions produit
• contexte business
• pratiques engineering

Ces skills peuvent ensuite être activées par les systèmes d'IA selon le contexte, quand c'est nécessaire.

Un exemple partagé par Alexandre : le reporting.

Alan a créé un workflow capable de rassembler automatiquement des informations depuis Slack, GitHub et les systèmes internes, pour générer des reportings hebdomadaires pour les personnes et les équipes.

Ça a réduit la quantité de travail opérationnel répétitif que les salariés devaient faire à la main.

« La partie logistique est de plus en plus prise en charge par l'IA, et je relis là où j'apporte le plus de valeur », Alexandre Gerlic

Ce qui est intéressant, c'est que ces workflows sont réutilisables et s'améliorent avec le temps. Les équipes transforment progressivement des tâches opérationnelles récurrentes en systèmes internes qui passent à l'échelle.

Cette approche aide aussi à diffuser le savoir de l'organisation de façon plus homogène entre les équipes.

‍

Éviter d'imposer des métriques trop tôt pendant l'adoption de l'IA

Alan a volontairement évité de trop mesurer l'adoption de l'IA pendant les premières étapes de la transformation.

Selon Alexandre, introduire les mauvaises métriques trop tôt pouvait créer de mauvaises incitations :

• trop de focus sur le volume de production
• moins d'expérimentation
• des contributions de moins bonne qualité
• des comparaisons de productivité artificielles

À la place, la boîte s'est d'abord concentrée sur des signaux qualitatifs :

• est-ce que les designers prototypent directement en production ?
• est-ce que les PMs testent leurs idées plus vite ?
• est-ce que les équipes corrigent les problèmes de façon plus autonome ?
• est-ce que les workflows changent naturellement ?

Ce n'est que plus tard qu'Alan a commencé à ajouter des métriques plus opérationnelles sur le code généré par l'IA et la performance des workflows.

La boîte a aussi commencé à analyser si les pull requests générées par l'IA passaient vraiment plus vite dans les workflows de production, ou si elles ajoutaient de la complexité à la review.

Cette approche itérative a permis aux équipes d'adapter leurs workflows avant de les optimiser à fond.

Elle a aussi réduit le risque de figer des comportements trop tôt, alors que l'écosystème d'outils évoluait encore très vite.

‍

L'un des plus gros défis : naviguer dans des outils instables

L'un des moments les plus difficiles pour Alan est arrivé pendant la première vague d'assistants de code IA.

Alexandre décrit une période où les discussions en ligne sur l'IA allaient beaucoup plus vite que la fiabilité réelle des outils disponibles en interne. Les équipes voyaient le potentiel, mais beaucoup de workflows restaient encore inégaux et immatures.

Ça a créé de l'incertitude dans les organisations.

Certaines premières expériences ont produit des gains utiles, d'autres ont eu un impact limité. Les équipes ont dû continuer à itérer pendant que les modèles et les outils progressaient vite, mois après mois.

Selon Alexandre, un apprentissage important a été de rester flexible sur l'organisation. Alan a sans cesse changé d'outils, de workflows et d'environnements au fil de l'évolution de l'écosystème.

La boîte a aussi beaucoup investi dans des boucles d'apprentissage internes :

• tester vite de nouveaux workflows
• partager les apprentissages entre équipes
• itérer sur les formations
• adapter les environnements en continu

Ça a aidé l'organisation à évoluer en même temps que la technologie, au lieu d'attendre un setup parfaitement stable avant d'avancer.

L'enseignement plus large : l'adoption de l'IA demande une adaptation continue de l'organisation, surtout quand les workflows et les outils évoluent encore très vite.

‍

• L'adoption se diffuse plus vite quand chaque équipe développe des workflows adaptés à son propre contexte et à ses propres contraintes opérationnelles.
• Des environnements d'outils partagés créent des boucles de collaboration plus fortes entre les équipes engineering, produit et design.
• Des garde-fous engineering solides deviennent essentiels quand des non-ingénieurs commencent à contribuer directement aux systèmes de production.
• L'IA réduit la friction d'implémentation, ce qui change la façon dont les équipes pensent la priorisation et l'ambition produit.
• Les petites équipes autonomes deviennent de plus en plus efficaces quand l'IA réduit la charge de coordination et d'exécution.
• Des skills IA réutilisables peuvent progressivement transformer le savoir opérationnel en infrastructure interne qui passe à l'échelle.
• Pendant les premières étapes de l'adoption de l'IA, les changements qualitatifs dans les workflows sont souvent de meilleurs indicateurs que les métriques de productivité.
• Les organisations ont besoin de boucles d'itération rapides, parce que les outils et les capacités de l'IA évoluent en continu.
• Les workflows de développement produit combinent de plus en plus idéation, prototypage et implémentation dans le même environnement opérationnel.
• La transformation IA demande autant d'adaptation de l'organisation que d'expérimentation technique.

‍