Brendan Humphreys (Canva) "80% des ingénieurs de Canva sont plus productifs grâce à l'IA"

Brendan Humphreys est le CTO de Canva. Il revient pour le JDN sur l'intégration de l'IA dans le cycle de développement logiciel au sein de ses équipes.

Brendan Humphreys est le CTO de Canva. © Canva

JDN. Comment vos équipes utilisent-elles l'IA dans leur cycle de production logicielle ? Avez-vous mis en place des outils internes, à l'image d'un Copilot, pour accompagner vos ingénieurs au quotidien ?

Brendan Humphreys. Nous avons une politique très libérale en matière d'adoption de l'IA chez Canva. Nous voulons que chaque employé expérimente ces outils pour comprendre comment il peut les appliquer à son travail. Nous avons donné un mandat assez large pour expérimenter, en créant du temps et de l'espace pour cela, et nous soutenons cette démarche avec des licences très permissives. Nous disposons donc de licences pour de très nombreux outils du marché. Dans le domaine de la technologie, nous utilisons la plupart des outils que vous connaissez : Sourcegraph, AMP code, Cursor, Claude, ChatGPT pour le code, etc. Nous mettons les licences à la disposition de nos ingénieurs de manière assez permissive. Si quelqu'un veut une licence pour un outil, il peut simplement l'obtenir.

Avec nos fournisseurs, nous insistons beaucoup pour obtenir une tarification basée sur la consommation plutôt que de payer pour des licences inutilisées. Nous avons 2 300 ingénieurs ; fournir une licence de chaque outil à chaque ingénieur devient très coûteux. Nous essayons donc de pousser les fournisseurs vers une tarification à l'usage. Parfois, nos ingénieurs nous proposent de nouveaux outils et nous avons également une communauté d'ingénieurs et un département IT très au fait des nouveautés. Nous sommes donc au courant des évolutions des outils et nous entretenons de bonnes relations directes avec beaucoup des grands fournisseurs, ce qui nous permet de savoir ce qui se prépare.

Lorsque vous achetez une licence, quels critères regardez-vous ?

Nous faisons prioritairement une analyse de sécurité. Nous avons un programme très sophistiqué d'analyse et de test des fournisseurs. Nous voulons donc savoir quels mouvements de données ont lieu autour de ces modèles, quelles données sont utilisées à des fins d'entraînement, et nous voulons comprendre les modèles de menace que ces LLM introduisent. Généralement, la voie que nous suivons est la suivante : nous effectuons une évaluation rapide de la menace. Une fois que l'équipe de sécurité est satisfaite, nous passons à un petit projet pilote. Ce programme pilote nous donne un retour rapide pour savoir si cet outil est adapté à nos besoins. Une fois que c'est un succès, nous envisageons alors un déploiement de licences plus permissif à l'ensemble du département technologique.

Vos équipes travaillent-elles principalement avec des IDE enrichis par l'IA, ou expérimentent-elles également des agents de code ?

Nous n'en sommes qu'au début de l'utilisation de l'automatisation complète avec des agents dans le software engineering. En ayant beaucoup de solutions d'agents commerciaux pour le développement logiciel, le défi est que notre base de code est tout simplement trop volumineuse. Nous avons des dizaines de millions de lignes de code, et la plupart des outils ne parviendraient même pas à cloner le dépôt GitHub.

"L'un des principaux avantages que nous observons est que ces outils permettent aux ingénieurs de rester beaucoup plus longtemps dans un état de flow"

Nous avons donc fait du développement en interne et nous avons les prémices d'un support "agentique" développé en interne. C'est certainement quelque chose que nous expérimentons. Nous discutons avec les principaux fournisseurs et nous espérons qu'ils prendront en charge ces cas d'usage plus importants, car c'est évidemment très lucratif pour eux. Nous pensons, par exemple, que Codex d'OpenAI est un excellent exemple dont nous attendons qu'il soit bientôt capable de gérer la taille de notre dépôt.

Le retour sur investissement de ces outils est-il déjà tangible ?

Beaucoup de métriques à la mode sont en réalité assez superficielles. Par exemple, quand des fournisseurs nous annoncent fièrement que "30% de leur code est généré par l'IA", je reste sceptique. Ce n'est pas du tout le genre de données que nous suivons chez nous. Ce qui m'intéresse davantage, c'est la perception que les ingénieurs ont de leur propre productivité. Sur ce point, nous constatons qu'environ 80% des ingénieurs se considèrent plus productifs en utilisant ces outils. Nous observons également une augmentation du volume de travail (de l'output, ndlr) chez les ingénieurs qui utilisent ces outils.

L'un des principaux avantages que nous observons est que ces outils permettent aux ingénieurs de rester beaucoup plus longtemps dans un état de flow. Vous avez ce pair programmer à vos côtés, qui agit comme un compagnon constant que vous pouvez consulter, mais à qui vous pouvez aussi commencer à déléguer des tâches lorsque vous êtes dans cet état de concentration. Auparavant, sans les outils d'IA, vous auriez pu interrompre une tâche pour, par exemple, remarquer quelque chose à corriger dans la base de code, puis vous seriez parti faire autre chose, et avant de vous en rendre compte, vous vous retrouviez à jongler avec trois tâches en même temps.

Au-delà de leurs bénéfices, avez-vous également identifié des limites ou des contraintes dans l'usage de ces outils d'IA par vos équipes ?

Nous savons pertinemment que les outils hallucinent. Ils se trompent parfois avec une assurance déconcertante. Ils doivent donc être supervisés par des ingénieurs humains hautement qualifiés. C'est une limitation indéniable. Nous constatons également que même les modèles les plus avancés, dotés de larges fenêtres de contexte, ne sont pas proportionnellement performants sur les grandes bases de code. Même avec une très grande fenêtre de contexte, on observe des rendements décroissants par rapport à sa taille.

Avez-vous constaté des différences dans la façon dont les développeurs juniors et seniors s'approprient et utilisent l'IA au quotidien ?

Oui, nous observons des différences. Les ingénieurs juniors utilisent ces outils pour prototyper et identifier des solutions techniques à leurs problèmes. Nos ingénieurs expérimentés, du niveau intermédiaire à senior, utilisent ces outils comme une sorte de super-pouvoir. Ils les intègrent dans leur IDE et les emploient comme un pair programmer pour vérifier leur travail et générer du code, tel une autocomplétion vraiment intelligente.

Envisagez-vous de recourir à des agents entièrement automatisés, capables non seulement de générer du code mais aussi d'assurer des tâches plus complexes, comme la migration ou la maintenance logicielle ?

A ce stade, nous ne voyons pas de place pour une automatisation complète. Ces outils doivent être supervisés. Je pense que l'automatisation qui nous enthousiasme intervient lorsque vous avez un problème bien défini : vous pouvez alors utiliser une solution de code agentique pour produire une proposition de solution. Mais cette proposition reste ensuite dans un environnement de développement ou de prototypage où un humain peut à la fois examiner le code et tester la fonctionnalité, et c'est cette personne qui valide finalement le changement. Je ne pense pas que ces outils soient suffisamment matures pour qu'on leur accorde une confiance totale en mode autonome.

Certaines entreprises envisagent déjà de substituer une partie des développeurs, notamment juniors, par l'IA. Pensez-vous que ce scénario pourrait se produire à terme, y compris chez Canva ?

A moyen terme, nous ne pensons certainement pas que ce soit une possibilité, pour les raisons que j'ai mentionnées. Je pense qu'en définitive, les humains doivent rester ceux qui guident, ceux qui exercent le jugement esthétique et définissent la qualité, ceux qui évaluent et assument la responsabilité du résultat final.

"Au final, le codage ne représente qu'une infime partie du métier de software engineer"

Pour cela, il est essentiel que des ingénieurs juniors continuent d'intégrer l'industrie, apportant leur enthousiasme, leur passion et leurs idées novatrices. Au final, le codage ne représente qu'une infime partie du métier de software engineer. Nous sommes enthousiasmés par ces outils qui nous assistent dans cet aspect, mais le métier de software engineer accompli comporte tellement d'autres dimensions que l'IA ne peut le remplacer. Même avec l'IA, nous voyons donc toujours un avenir prometteur pour les ingénieurs juniors dans le domaine du software engineering.