Werner Vogels, Amazon: «Il ne s’agit pas de faire confiance aux modèles d’IA, mais à l’architecture qui les entoure»
Rencontré à Genève à l’occasion de l’AI for Good Global Summit, Werner Vogels, CTO d’Amazon, défend une approche prudente de l’intelligence artificielle. Pour lui, la confiance ne doit pas reposer sur les modèles eux-mêmes, mais sur les architectures, les contrôles et les garde-fous qui les entourent. Il évoque aussi l’évolution du métier de développeur et l’urgence de se préparer à la cryptographie post-quantique.
Lors de votre keynote à l’AI for Good Global Summit 2026, vous avez insisté sur la question de la confiance dans l’intelligence artificielle. Pourquoi cet enjeu vous paraît-il central?
Il faut d’abord comprendre que ces systèmes ne sont pas conçus pour produire la vérité. Ils sont conçus pour générer ce qui est possible ou probable dans un contexte donné. C’est le principe même des grands modèles de langage. Nous connaissons leurs hallucinations et devons accepter qu’ils puissent se tromper. La question devient donc: comment utiliser un système dont on sait qu’il peut produire une réponse erronée? Dans une activité commerciale, une entreprise peut parfois accepter ce risque, effectuer des vérifications ou corriger une erreur. Dans les domaines humanitaires ou auprès de populations vulnérables, les conséquences peuvent être beaucoup plus importantes. Si les personnes ne font pas confiance au système, elles ne l’utiliseront pas.
Comment établir cette confiance?
Elle commence notamment par la langue. Je dirige une initiative appelée CTO Fellowship, qui réunit actuellement 22 responsables technologiques dans 14 pays. Parmi les organisations accompagnées figure Jacaranda Health, au Kenya. Elle a développé un service par SMS permettant aux femmes enceintes ou ayant récemment accouché de poser des questions sur leur santé. Le système ne répond pas en anglais ni nécessairement dans la langue officielle du pays, mais dans la langue locale de l’utilisatrice. C’est important, car une langue véhicule aussi une culture. Ce choix contribue directement à la confiance. L’architecture prévoit également que certains mots-clés associés à un risque, par exemple un saignement, empêchent toute réponse automatisée. La demande est alors transmise à un médecin. La technologie n’est donc pas seule à décider.
Le niveau de contrôle doit-il dépendre du cas d’usage?
Absolument. Si un système établit une liste de livres populaires et commet une petite erreur, les conséquences restent limitées. Dans la santé, une erreur peut coûter une vie. Entre ces deux extrêmes, les entreprises doivent définir le niveau de risque qu’elles acceptent. Dans un secteur réglementé, qu’il s’agisse de la santé ou des services financiers, ce n’est pas le système d’IA qui sera tenu responsable en cas de problème. Ce sera l’entreprise. Il ne s’agit donc pas de faire confiance aux modèles d’IA eux-mêmes, mais à l’architecture qui les entoure. Ce principe n’est pas nouveau. Lorsque vous montez dans un avion, vous faites confiance à l’ensemble du système. Plusieurs ordinateurs peuvent exécuter les mêmes opérations. Si leurs résultats divergent, le système suspend l’action ou transmet la décision au pilote. Pour les applications d’IA présentant un risque élevé, une approche similaire peut être mise en œuvre. Plusieurs modèles peuvent répondre à la même question, puis leurs résultats être comparés. S’ils convergent, une action peut être envisagée. S’ils divergent, la décision doit revenir à un humain ou faire l’objet d’une nouvelle analyse.
Cette précaution devient-elle plus importante avec les agents IA?
Oui. Avec un chatbot, un humain voit généralement la réponse avant d’agir. Son intuition peut l’amener à se demander si le résultat est réellement crédible. Un agent, en revanche, peut entreprendre des actions de manière autonome. Avant de lui permettre d’agir dans un environnement opérationnel, il faut donc disposer d’un niveau de confiance élevé. Il est possible de confronter les réponses de modèles développés par plusieurs fournisseurs. En cas de désaccord, on peut transmettre le dossier à un humain ou demander aux modèles d’évaluer les différentes réponses jusqu’à l’obtention d’un consensus. C’est comparable à la sécurité informatique. Je n’ai pas besoin de faire confiance isolément à ma carte mère ou à mon routeur. La sécurité est une propriété de bout en bout. C’est l’ensemble du système qui doit être digne de confiance.
La qualité des données reste toutefois déterminante. Comment limiter les biais?
Il faut examiner très précisément les données utilisées. La ville de Rotterdam avait développé un système d’IA destiné à détecter la fraude aux prestations sociales. Elle souhaitait éviter toute discrimination fondée sur le statut migratoire et n’avait donc pas intégré directement cette information. Mais le système utilisait le niveau de maîtrise du néerlandais. Cette donnée s’est révélée être un indicateur indirect de l’origine migratoire. Les personnes immigrées ont ainsi été contrôlées de manière disproportionnée. Même lorsqu’une variable sensible est retirée, une autre peut servir de substitut. La transparence des jeux de données est donc essentielle. Le modèle suisse Apertus constitue à cet égard un bon exemple. Son caractère ouvert permet d’examiner les données et les principes qui ont présidé à son entraînement, notamment en matière de droit d’auteur et de conformité réglementaire. Il faut pouvoir les inspecter, comprendre leur provenance et identifier les biais qu’ils contiennent éventuellement. Les fournisseurs devraient aussi être capables d’expliquer pourquoi leur système produit une réponse donnée. Les premiers grands modèles ont notamment été entraînés sur des données issues de plateformes en ligne qui ne constituent pas nécessairement les sources les plus fiables. Les opinions les plus extrêmes y sont souvent les plus visibles. Cette caractéristique peut introduire des biais dans les modèles.
Les modèles restent pourtant souvent décrits comme des boîtes noires. Peut-on vraiment expliquer leur fonctionnement?
C’est encore un domaine de recherche. Mais même lorsqu’il n’est pas possible d’expliquer parfaitement un modèle, on peut mettre en place des garde-fous autour de lui. Chez AWS, nous utilisons notamment le raisonnement automatisé. Une entreprise peut formaliser les règles auxquelles une réponse doit se conformer, puis vérifier automatiquement qu’elles sont respectées. Il ne s’agit pas seulement de bloquer des contenus abusifs. Les exigences internes ou réglementaires peuvent aussi être traduites sous forme de spécifications formelles. Le système peut alors signaler une réponse qui enfreint ces règles. Cela permet d’augmenter le niveau de confiance, même lorsque le fonctionnement interne du modèle ne peut pas être entièrement retracé.
Vous conseillez aussi aux entreprises de ne pas se précipiter dans l’adoption de l’IA. Pourquoi?
Les dirigeants sont exposés chaque semaine à un nouveau concept: IA générative, modèles de pointe, agents ou autres évolutions. Cette succession crée une peur de manquer quelque chose. Lorsque des CIO ou des CTO me demandent ce qu’ils devraient faire avec l’IA, je commence souvent par leur demander pourquoi ils estiment devoir l’utiliser. Ils doivent partir du problème à résoudre, puis déterminer quelle technologie est adaptée. Il ne faut pas avoir peur d’appuyer sur le bouton pause, de se former et d’évaluer les capacités réelles des outils. Les développeurs de l’organisation disposent souvent déjà d’une compréhension assez précise de ce qui fonctionne. Les dirigeants devraient davantage discuter avec leurs propres équipes techniques.
Dans vos dernières «Tech Predictions», vous évoquez l’émergence du «développeur de la Renaissance». Que recouvre cette expression?
Beaucoup de développeurs craignent de perdre leur emploi parce que les outils d’IA peuvent générer du code beaucoup plus rapidement. Mais l’arrivée de nouveaux outils ne rend pas l’être humain obsolète. Elle peut au contraire renforcer ses capacités, à condition d’adapter sa manière de travailler. Une expertise approfondie reste utile. Mais un ingénieur devient plus efficace lorsqu’il comprend aussi le contexte plus large dans lequel son travail s’inscrit. Le développeur de la Renaissance combine une spécialisation avec une vision plus étendue des systèmes, des utilisateurs et des problèmes métiers.
Quelles compétences les universités devraient-elles alors enseigner?
Avant tout, apprendre à apprendre. Au cours de ma carrière, j’ai utilisé de nombreuses générations d’environnements de développement. Les outils continueront à changer. Un ingénieur doit être capable de se former tout au long de sa vie. Les compétences de communication sont également cruciales. Il faut savoir écrire, interroger un client et comprendre son véritable problème. Un client arrive souvent avec une solution technologique en tête parce qu’il en a entendu parler. Le rôle de l’ingénieur consiste à aller plus loin et à déterminer le besoin réel. La collaboration est tout aussi importante. Je m’intéresse notamment à la manière dont les jeunes ingénieurs ont travaillé avec d’autres personnes ou participé à des projets open source. Le fait de réaliser des revues de code avec des ingénieurs expérimentés permet d’acquérir une culture et un jugement qui ne s’apprennent pas uniquement dans les livres.
La génération automatique de code modifie-t-elle ce processus d’apprentissage?
Nous pouvons désormais générer du code plus vite que nous ne pouvons le comprendre. Lorsque nous écrivions nous-mêmes chaque ligne, nous internalisions progressivement le fonctionnement du système. Si une grande partie du code est produite automatiquement, la revue devient encore plus importante. Il faut aussi se demander comment un ingénieur junior deviendra senior s’il ne passe plus par les mêmes étapes de construction. Une partie de l’apprentissage devra venir de la collaboration, des revues de code et du travail aux côtés d’ingénieurs expérimentés. La qualité compte davantage que la quantité de code générée. La communication humaine ne disparaît donc pas. Elle devient au contraire l’un des mécanismes permettant de maintenir cette qualité.
Vous appelez par ailleurs les entreprises à adopter rapidement une protection post-quantique. N’est-ce pas prématuré?
Non, car les données peuvent être collectées aujourd’hui et déchiffrées plus tard. Des acteurs peuvent intercepter des informations chiffrées sans être actuellement capables de les lire, puis attendre que les ordinateurs quantiques rendent leur déchiffrement possible. Les organisations qui détiennent des données médicales, financières ou d’autres informations sensibles doivent donc les protéger dès maintenant. AWS a développé une boîte à outils open source de chiffrement résistant aux attaques quantiques. Il faut également rappeler que la sécurité ne constitue pas seulement un coût. Sans sécurité adéquate, une entreprise peut cesser de fonctionner. Les incidents liés aux rançongiciels montrent souvent que des systèmes n’ont pas été corrigés ou mis à jour. De nombreux équipements utilisent encore d’anciennes versions de logiciels dont les vulnérabilités sont connues. La technologie évoluera encore et d’autres mécanismes apparaîtront probablement dans dix ans. Mais le risque existe aujourd’hui. Attendre que les ordinateurs quantiques soient largement disponibles pour réagir reviendrait à agir trop tard.
L’actualité IT en Suisse et à l’international, avec un focus sur la Suisse romande, directement dans votre boîte mail > Inscrivez-vous à la newsletter d’ICTjournal, envoyée du lundi au vendredi!
