🚀 IA : Andrew Feldman (Cerebras) calme les craintes
Découvrez comment Andrew Feldman (Cerebras) arbitre risques de l’IA et bénéfices : enjeux, éthique IA et centres de données pour les entreprises.
IA : faut-il parler davantage de ses bénéfices que de ses risques ?
L'intelligence artificielle est souvent racontée avec deux images qui s'opposent. D'un côté, la promesse d'avancées médicales, de gains de productivité et de nouveaux services. De l'autre, des avertissements sur des systèmes incontrôlables, des emplois fragilisés et des risques qui peuvent aller très loin. Pour les entreprises comme pour le public, cette tension rend le débat difficile à suivre : faut-il accélérer, ralentir, réguler, ou simplement attendre d'en savoir plus ?
Lors de TechCrunch Disrupt 2026, Andrew Feldman, cofondateur et dirigeant de Cerebras Systems, a contesté la place prise par les scénarios les plus sombres. Selon lui, insister surtout sur les risques finit parfois par masquer les bénéfices possibles. Il cite notamment des progrès médicaux, tout en rappelant qu'une technologie puissante peut aussi être détournée. Son point de vue vaut d'être examiné : Cerebras fournit des composants à des acteurs majeurs de l'IA, donc l'entreprise a aussi un intérêt à ce que le secteur continue de croître. Au fond, il ne s'agit pas de choisir entre enthousiasme et peur, mais de clarifier comment on parle des bénéfices, comment on traite les risques et comment on décide, concrètement.
Un débat sur l'IA devenu difficile à équilibrer
À TechCrunch Disrupt, Andrew Feldman a lancé une pique aux responsables du secteur qui mettent en avant les scénarios les plus inquiétants : certains dirigeants de l'IA, a-t-il plaisanté, devraient peut-être éviter de s'exprimer en public. Derrière la boutade, il décrit un phénomène réel : les mises en garde sur les dangers de l'IA ont pris une place importante dans le débat public, au point d'être reprises (et parfois parodiées) dans la culture populaire.
Ce constat ne suffit pas à dire que les risques sont exagérés. Il indique plutôt que la communication autour de l'IA est devenue une partie du problème. Quand on évoque des scénarios extrêmes sans préciser les mécanismes, le public retient surtout une impression générale de menace - sans savoir quels risques sont déjà documentés, lesquels relèvent encore de l'hypothèse, et quelles mesures permettent réellement de réduire le danger. À l'inverse, un discours centré uniquement sur les gains économiques ou les prouesses techniques peut aussi sonner faux.
Les scénarios extrêmes ne sont pas un plan de gestion des risques
Parler de l'hypothèse qu'une IA puisse devenir incontrôlable peut être légitime. Mais la discussion n'aide vraiment que si elle conduit à des décisions : de quelles capacités parle-t-on ? Quels usages sont concernés ? Quelles évaluations ou restrictions sont nécessaires ? Qui intervient si un système échoue ? Sans ces réponses, même une alerte formulée par un expert peut vite devenir un signal d'alarme difficile à traduire en action.
Les responsables d'entreprise rencontrent le même mur, à leur échelle. Dire « l'IA comporte des risques » ne dit rien de suffisant pour décider si on peut l'utiliser pour résumer des documents, analyser des dossiers clients ou automatiser une étape de production. Il faut préciser ce qui se passe en cas d'erreur : quelles conséquences, quelles données, quel niveau de contrôle humain, et surtout comment on revient en arrière.
Le risque de fatigue et la perte de confiance
Un discours uniquement alarmiste peut créer de l'inquiétude, mais aussi de la lassitude. Si les annonces se succèdent sans distinguer les probabilités, les délais et les usages, une partie du public finit par décrocher. Et c'est justement là le problème : une alerte crédible sur un danger concret peut se retrouver banalisée, rangée au même niveau qu'une déclaration spectaculaire.
La réponse n'est donc ni de demander aux dirigeants de se taire, ni de remplacer les mises en garde par des promesses. Elle consiste surtout à rendre le débat plus exploitable. Une communication responsable devrait expliquer ce que le système sait faire, dans quelles conditions il échoue, qui bénéficie de son déploiement et qui supporte ses coûts. La question n'est pas « l'IA est-elle bonne ou mauvaise en général ? ». La question utile est plutôt : quels usages créent une valeur vérifiable, et dans quelles conditions ?
Promesses et intérêts économiques : séparer les faits des récits
Feldman met en avant le potentiel médical de l'IA et évoque un avenir où certaines maladies graves reculeront fortement. L'image est intéressante, mais il faut la traiter comme un objectif possible, pas comme une certitude. Une technologie peut aider à analyser des données ou à accélérer la recherche, sans pour autant garantir qu'un traitement sera découvert, validé, disponible et efficace pour tous.
En santé comme dans l'industrie ou les services, le chemin entre une capacité technique et un bénéfice réel est rarement direct. Il faut des données adaptées, des essais solides, une intégration dans les pratiques existantes et une responsabilité clairement définie. Un modèle performant en laboratoire ne devient pas automatiquement un outil fiable en conditions réelles. Cette nuance pèse lourd quand on juge les promesses commerciales.
Évaluer les bénéfices à partir d'usages mesurables
Pour une organisation, les bénéfices ne se résument pas au nombre de tâches automatisées. Cela peut aussi vouloir dire : réduire les délais, améliorer la qualité de service, diminuer les erreurs, ou dégager du temps pour les cas complexes. Mais ces résultats doivent être mis en balance avec le coût total : intégration, licences, infrastructure, supervision, sécurité et maintien à jour.
Une façon simple et pragmatique de commencer consiste à partir d'un processus précis plutôt que d'une ambition générale du type « devenir une entreprise augmentée par l'IA » :
- Décrire le problème métier et son coût actuel, en temps, en erreurs ou en expérience client.
- Définir une mesure de réussite qui pourra être comparée avant et après le déploiement.
- Tester l'outil sur un périmètre limité, avec des cas représentatifs et des exceptions.
- Mesurer les erreurs et le temps de vérification, pas seulement la vitesse de génération.
- Décider ensuite : poursuivre, modifier ou arrêter selon les résultats.
Ce cadre évite de confondre une démonstration impressionnante et une amélioration réelle des opérations. Si un assistant produit un brouillon plus vite, mais oblige ensuite à une vérification complète, le gain peut être limité. Si, au contraire, une solution réduit le délai sans dégrader la qualité ni augmenter les risques juridiques, elle peut alors justifier son coût.
Tenir compte de l'intérêt de celui qui parle
Cerebras fabrique des puces pour l'IA. L'entreprise travaille avec des acteurs du secteur comme OpenAI, Block, Figma, GSK et Lovable, d'après TechCrunch. Le dirigeant défend donc forcément un secteur où la croissance profite aussi à son entreprise. Cela ne rend pas ses propos forcément faux, mais c'est un facteur à garder en tête pour les évaluer.
La même règle s'applique partout. Un fournisseur aura tendance à mettre en avant les gains de productivité ; une organisation préoccupée par la sécurité insistera sur les scénarios de défaillance ; une entreprise qui gère de grosses infrastructures n'aura pas la même lecture qu'une collectivité qui en subit les impacts. Pour décider, il faut regarder les incitations, demander des preuves et confronter les affirmations aux résultats observés.
RĂ©guler l'IA sans faire semblant que le risque n'existe pas
Feldman reconnaît qu'une technologie puissante peut être utilisée par des personnes mal intentionnées. Il estime donc nécessaire d'agir avec prudence et de mettre en place une régulation raisonnable. Sa position est plus nuancée que l'opposition classique entre « innovation sans contraintes » et « interdiction préventive » : il s'agit de permettre certains usages tout en limitant les dommages prévisibles.
Le mot clé, c'est « raisonnable ». Une règle trop vague laisse les organisations sans repères. Une règle mal ciblée peut aussi imposer le même niveau de contrôle à des applications dont les conséquences ne sont pas comparables. Reformuler un texte interne n'expose pas les personnes aux mêmes conséquences que la décision d'accorder l'accès à un service essentiel, ou que des décisions qui touchent directement aux droits.
Faire dépendre les contrôles des conséquences
Une gouvernance utile commence par classer les usages selon leurs impacts. Pour chacun, une organisation peut se demander :
- Qu'est-ce que le système influence exactement : une décision, une tâche, un tri ?
- Quelles personnes peuvent subir les conséquences d'une erreur ?
- Quelles données sont utilisées, et où sont-elles traitées ?
- L'utilisateur peut-il vérifier le résultat ou contester une décision ?
- Y a-t-il un mode dégradé si le système devient indisponible ?
À partir de là , on choisit les contrôles : documentation, tests, vérification humaine, journalisation, règles d'accès, procédures d'incident. Le cadre européen, notamment le règlement sur l'intelligence artificielle, ajoute aussi des obligations selon les catégories de systèmes et leurs usages. Les entreprises doivent également vérifier les exigences liées à la protection des données, comme le RGPD, quand des données personnelles sont en jeu. Les textes applicables changent : la checklist ne remplace pas une analyse juridique au moment du déploiement.
La responsabilité ne s'arrête pas au fournisseur
Un fournisseur peut documenter son produit et proposer des garanties. Mais l'organisation qui intègre le système garde les responsabilités opérationnelles : choix du cas d'usage, nature des données, niveau de supervision, et personnes qui utilisent (et interprètent) les résultats. Dans la pratique, beaucoup de défaillances ne viennent pas uniquement du modèle : elles apparaissent aussi dans le processus autour de lui.
C'est pour ça qu'une politique interne doit préciser qui décide, quels outils sont autorisés, quelles informations ne doivent pas être transmises, et comment signaler un résultat manifestement erroné. Elle doit aussi prévoir une révision régulière du dispositif. Un modèle, ses conditions d'accès et son environnement de données peuvent évoluer : un contrôle au lancement ne garantit pas la fiabilité dans le temps.
Centres de données : l'acceptabilité est aussi un enjeu technologique
Feldman relie une partie des critiques adressées à l'IA aux infrastructures qui la rendent possible. La demande en calcul entraîne la construction de centres de données, qui mobilisent des terrains, de l'électricité et des ressources locales. D'après lui, l'industrie a parfois assez peu travaillé avec les communautés concernées, notamment aux États-Unis, et a insuffisamment expliqué ses projets.
Le sujet compte particulièrement pour les entreprises européennes. L'IA ne vit pas seulement dans le nuage : elle dépend d'équipements et de bâtiments physiques, reliés à des réseaux électriques et situés sur des territoires où d'autres besoins existent. Même quand le service paraît immatériel pour l'utilisateur, le déploiement à grande échelle a des effets concrets : énergie, aménagement, et arbitrages d'investissement.
La concertation ne se résume pas à une communication de crise
Informer les riverains une fois le projet presque bouclé, ce n'est pas vraiment « travailler avec eux ». Une démarche crédible commence plus tôt : expliquer la taille et le calendrier, présenter les besoins en ressources, écouter les préoccupations et préciser ce qui peut, ou non, changer. Les collectivités et les habitants ne veulent pas seulement une brochure plus claire : ils veulent savoir ce qui va réellement évoluer chez eux, et qui porte les conséquences.
Feldman cite plusieurs pays - le Brésil, le Canada, la Finlande, l'Islande, la Norvège, le Mexique et la Suède - comme des marchés qui encouragent les entreprises à construire des centres de données. Comparer ces situations n'apporte pas la preuve que tout y est simple, ni que les enjeux locaux sont réglés. Mais cela rappelle que l'accueil d'infrastructures dépend aussi de choix publics, de la disponibilité énergétique et du dialogue entre opérateurs et territoires.
Pour les entreprises, le permis social compte dans le calcul
L'acceptabilité locale n'est pas un détail à traiter après l'ingénierie. Une opposition peut ralentir un projet, compliquer le raccordement et abîmer la réputation. À l'inverse, une concertation suffisamment tôt peut faire remonter des contraintes que les équipes techniques n'avaient pas vues, et éviter de concevoir une solution difficile à exploiter.
Un projet d'IA devrait donc être évalué sur plusieurs plans : valeur créée pour l'activité, coût d'infrastructure, consommation énergétique, dépendances vis-à -vis des fournisseurs, effets sur les territoires. Une entreprise n'a pas forcément besoin de posséder son centre de données pour être concernée : les choix de capacité et d'hébergement de ses prestataires peuvent peser sur ses coûts, sa résilience et son bilan environnemental.
Efficacité des puces : un gain technique ne garantit pas une baisse de la demande
Feldman ne s'inquiète pas d'une baisse mécanique de la demande grâce à des puces plus efficaces. Son raisonnement est que les fournisseurs de matériel améliorent l'efficacité du calcul, pendant que les concepteurs de modèles réduisent les ressources nécessaires pour obtenir un résultat donné. Dans cette logique, le secteur peut progresser au lieu de se contracter.
Sur le papier, c'est cohérent avec la réalité de l'ingénierie : gagner en efficacité peut réduire le coût d'un usage et rendre possibles de nouvelles applications. Mais on ne peut pas en déduire à l'avance la consommation totale. Quand le coût par opération baisse, les organisations peuvent aussi multiplier les usages ou utiliser des modèles plus grands. Au final, tout dépend de la manière dont le marché absorbe les gains.
Distinguer l'efficacité par requête de l'impact total
Pour piloter une infrastructure, il est utile de séparer deux choses : les ressources nécessaires à une tâche donnée, et les ressources consommées par l'ensemble des usages. La première peut s'améliorer, tandis que la seconde augmente, si l'activité se développe plus vite que l'efficacité.
Cette distinction concerne directement les acheteurs d'IA. Le coût d'une requête, la latence ou la puissance de calcul ne suffisent pas pour estimer le coût global de possession. Il faut aussi compter les appels répétés, les traitements de contrôle, le stockage, les besoins de sécurité, et le travail humain nécessaire pour traiter les cas que l'automatisation ne gère pas correctement.
Le bon arbitrage dépend de l'usage, pas du dernier matériel
Les équipes techniques peuvent réduire la facture en choisissant un modèle adapté à la tâche, en limitant le contexte inutile, en mettant en cache ce qui est réutilisable, ou en évitant d'appeler un modèle quand des règles plus simples suffisent. Mais ces gains doivent être mesurés : une optimisation peut réduire les coûts tout en dégradant la qualité, ou en rendant le système plus dur à maintenir.
La décision d'architecture doit donc regarder le service dans son ensemble, pas seulement la puce ou le modèle le plus récent. Pour une entreprise, la question utile ressemble à ceci : quelle combinaison de matériel, de modèle, de données et de contrôles répond au besoin avec un coût acceptable ? Une solution techniquement élégante peut être un mauvais choix si elle impose une équipe rare, ou si elle crée une dépendance difficile à gérer.
Conclusion : un débat utile doit conduire à des décisions
La prise de parole d'Andrew Feldman remet un point sur la table : parler des dangers de l'IA sans parler de ses usages bénéfiques produit une image incomplète. Mais l'argument inverse est tout aussi vrai : mettre en avant des avancées médicales potentielles ou des gains de productivité ne suffit pas à prouver, dans un contexte donné, que les systèmes sont sûrs, utiles et économiquement viables.
Pour les entreprises, la bonne approche n'est ni l'adoption automatique, ni l'attente d'une technologie parfaite. Il faut tester des cas d'usage précis, mesurer la valeur obtenue, proportionner les contrôles aux conséquences d'une erreur, et tenir compte à la fois des coûts d'infrastructure et des incitations des fournisseurs. C'est aussi ce qui permet de transformer un débat abstrait sur l'avenir de l'IA en décisions vérifiables.
Avant votre prochain projet, choisissez un processus concret, définissez ce qui constituerait une amélioration et fixez les conditions qui vous feraient arrêter l'expérimentation. C'est une base plus solide qu'une promesse générale - ou qu'une peur sans plan d'action.