L’inférence robotique de NVIDIA s’embarque, mais les datacenters voient toujours plus grand

L’inférence robotique de NVIDIA s’est beaucoup rapprochée de la machine, malgré des années de développement de l’IA centrées sur des datacenters distants. Jetson Thor offre aux fabricants de robots suffisamment de puissance de calcul embarquée pour exécuter plusieurs modèles exigeants sans attendre que chaque décision traverse un réseau.

Cette évolution ne rend pas le cloud obsolète. Elle instaure une séparation plus nette entre le contrôle physique immédiat et le raisonnement coûteux en calcul. Les robots ont besoin de réflexes locaux, tandis que les datacenters proposent toujours des modèles plus grands, une mémoire partagée, des mises à jour plus simples et une meilleure utilisation des ressources.

L’enjeu central n’oppose donc pas le matériel en périphérie à l’infrastructure cloud. Il oppose l’autonomie locale à l’intelligence centralisée, chaque entreprise de robotique décidant où placer la frontière. Google DeepMind, NVIDIA et les fabricants de robots construisent déjà autour de différentes versions de cette répartition.

L’inférence robotique de NVIDIA est arrivée dans la machine

NVIDIA a fait de l’inférence embarquée, autrefois une solution de repli contrainte, une base crédible pour des comportements robotiques sophistiqués.

Le signal matériel le plus clair est venu avec la disponibilité générale de Jetson AGX Thor en août 2025. NVIDIA a conçu cet ordinateur compact pour les humanoïdes, les machines industrielles, les dispositifs médicaux et d’autres systèmes qui traitent des données de capteurs en temps réel.

L’entreprise affirme que Jetson Thor fournit 7,5 fois plus de puissance de calcul IA que Jetson AGX Orin. NVIDIA fait également état d’une efficacité énergétique 3,5 fois supérieure à celle de son prédécesseur.

Ces comparaisons restent des affirmations du fournisseur, et les performances réelles dépendent du modèle, de la précision, de l’usage mémoire et de la configuration logicielle. Néanmoins, les spécifications fondamentales de la plateforme expliquent pourquoi l’emplacement de l’inférence robotique est devenu une question architecturale urgente.

Jetson AGX Thor comprend 128GB de mémoire et délivre jusqu’à 2 070 téraflops FP4, selon NVIDIA. FP4 est un format numérique compact sur quatre bits qui réduit le stockage et les calculs des modèles, au prix d’une certaine perte de précision.

La capacité mémoire compte autant que le chiffre phare de calcul. Un robot peut exécuter simultanément des charges de travail de perception, de langage, de cartographie, de planification de mouvement et de sécurité. Chacune rivalise pour la bande passante mémoire, le temps de traitement et un budget énergétique limité.

NVIDIA indique que sa communauté de logiciels robotiques réunit plus de deux millions de développeurs. Parmi les premiers adopteurs de Thor cités par l’entreprise figurent Amazon Robotics, Boston Dynamics, Figure, Agility Robotics, Caterpillar et Medtronic.

Cette liste couvre les entrepôts, les humanoïdes, les équipements lourds et la santé. Elle suggère que l’IA embarquée devient une décision d’infrastructure partagée plutôt qu’une fonctionnalité de niche réservée à une catégorie de robots.

Google DeepMind a fait progresser le sujet côté modèles. Son modèle local pour la robotique a été présenté en juin 2025 comme un système vision-langage-action optimisé pour fonctionner directement sur les robots.

Un modèle vision-langage-action, généralement appelé VLA, traduit des images et des instructions en actions physiques. Il réunit perception visuelle, compréhension du langage et contrôle moteur au sein d’un même système appris.

DeepMind a présenté son modèle comme utile lorsque la latence réseau ou la connectivité limiteraient un robot dépendant du cloud. Selon l’entreprise, le modèle peut aussi s’adapter à de nouvelles tâches grâce à des démonstrations supplémentaires.

Ces lancements ont modifié le point de départ pratique de l’architecture robotique. Les développeurs ne doivent plus supposer que la perception avancée et la manipulation généraliste exigent une connexion permanente à un datacenter.

Cependant, ni NVIDIA ni Google n’ont établi que chaque couche de l’intelligence robotique devait être embarquée. Leurs produits rendent plutôt possible une conception hybride, ce qui soulève des décisions plus difficiles quant aux calculs qui doivent rester locaux.

Un robot ne peut pas attendre que le cloud le rattrape

Les systèmes physiques imposent des échéances à l’intelligence, et manquer ces échéances peut compter davantage que produire la réponse la plus sophistiquée.

Un chatbot peut marquer une pause pendant qu’un modèle distant génère une réponse. Un robot qui se tient en équilibre sur deux jambes, évite un travailleur ou saisit un matériau fragile ne peut pas considérer un délai réseau imprévisible comme un simple désagrément.

Chaque requête au cloud ajoute plusieurs étapes. Le robot doit encoder les informations des capteurs, les transmettre, attendre le traitement distant, recevoir un résultat et vérifier que l’instruction reste pertinente.

Le monde physique peut changer pendant ce parcours. Une personne peut s’engager sur le trajet, un objet peut glisser ou un véhicule peut entrer dans une intersection. Une réponse correcte mais tardive peut devenir, dans les faits, incorrecte.

Cette contrainte favorise les boucles de contrôle locales. Une boucle de contrôle mesure à plusieurs reprises un système, calcule une correction et l’applique afin de maintenir la stabilité du mouvement.

L’équilibre de bas niveau, l’évitement des collisions, le contrôle des articulations et l’arrêt d’urgence doivent rester près du matériel. Ces fonctions nécessitent un comportement déterministe, c’est-à-dire un temps de réponse maintenu dans une plage connue.

La connectivité introduit de la variabilité même lorsque la latence moyenne paraît acceptable. La congestion, une couverture faible, des problèmes de routage et les interruptions de service créent des retards extrêmes que les moyennes masquent.

Le fonctionnement hors ligne est également important au-delà des sites isolés. Les usines peuvent isoler leurs réseaux de production pour des raisons de sécurité. Les hôpitaux peuvent limiter les transferts de données externes, tandis que les fermes et les chantiers manquent souvent de connectivité fiable.

La confidentialité renforce la même pression architecturale. Les robots peuvent collecter des vidéos, des données audio, des cartes spatiales, des informations médicales et des observations provenant de domiciles privés. Envoyer chaque flux brut de capteurs à un service distant élargit la surface d’exposition.

Le traitement local peut éliminer les informations inutiles avant leur transmission. Un robot d’entrepôt pourrait envoyer un rapport d’exception compact plutôt qu’une vidéo continue des environs des travailleurs.

La bande passante constitue une autre contrainte. Plusieurs caméras, microphones, capteurs de profondeur et systèmes lidar peuvent générer des flux continus. Tout téléverser consommerait la capacité réseau avant même que le datacenter commence son travail d’inférence.

Le filtrage sur l’appareil permet au robot de décider quelles observations méritent une analyse distante. Il peut conserver la navigation de routine en local et transmettre les situations inhabituelles avec des images sélectionnées, des résumés d’état ou un contexte compressé.

L’énergie complique le tableau. Le calcul local consomme la batterie et produit de la chaleur, mais la transmission sans fil a aussi un coût énergétique. La meilleure option dépend des conditions radio, de la taille de la charge de travail et des accélérateurs disponibles.

La sécurité fait de ce sujet bien davantage qu’une optimisation d’infrastructure. Un robot devrait rester contrôlable lorsque sa connexion cloud disparaît. Cette exigence place les réflexes essentiels, les limites opérationnelles et les comportements de repli sur la machine.

Le cloud peut toujours conseiller le robot. Il ne devrait pas devenir le seul composant capable de l’arrêter.

Pour l’inférence robotique de NVIDIA, l’opportunité est donc précise. Les processeurs embarqués peuvent prendre en charge le chemin sensible au temps, même lorsqu’un modèle distant plus grand gère le travail délibératif.

Les datacenters conservent l’avantage au sommet de l’intelligence

Les puces locales améliorent la réactivité d’un robot, mais les datacenters gardent un avantage décisif lorsqu’une tâche exige de l’échelle, de la mémoire ou des calculs partagés.

Un ordinateur robotique fonctionne sous des contraintes strictes. Sa mémoire, sa capacité de refroidissement, son autonomie, son espace physique et son coût de fabrication sont limités. Augmenter une ressource aggrave souvent une autre contrainte.

Les datacenters peuvent répartir un modèle sur de nombreux accélérateurs. Des interconnexions à haut débit permettent à ces accélérateurs de partager des paramètres et des données intermédiaires qui ne tiendraient pas dans un seul robot.

Cette différence fixe un plafond d’intelligence. Un modèle compact peut gérer des objets courants et des instructions familières, tandis qu’un modèle distant examine des situations rares avec des connaissances plus vastes et un contexte plus long.

La taille d’un modèle n’est pas une mesure parfaite de ses capacités. Des systèmes plus petits peuvent surpasser des systèmes plus grands lorsqu’ils sont optimisés pour une tâche étroite. Pourtant, les grands modèles distants restent utiles pour les demandes inconnues, la planification en plusieurs étapes et des connaissances étendues sur le monde.

Les datacenters bénéficient aussi du traitement par lots. Celui-ci regroupe les requêtes de plusieurs utilisateurs ou machines, ce qui permet aux accélérateurs coûteux de les traiter plus efficacement.

SemiAnalysis a décrit le compromis d’inférence qui en résulte entre le débit du système et l’interactivité individuelle. Les grands lots améliorent l’utilisation du matériel, tandis que les lots plus petits offrent généralement des réponses plus rapides à chaque utilisateur.

Un robot isolé ne peut pas reproduire cette économie. Son processeur peut rester sous-utilisé pendant le fonctionnement courant tout en devant disposer d’une capacité suffisante pour le moment local le plus exigeant.

L’infrastructure centralisée mutualise cette demande à l’échelle d’une flotte. Un cluster distant peut servir de nombreux robots dont les requêtes difficiles arrivent à des moments différents.

Les mises à jour sont également plus simples dans le datacenter. Un opérateur peut déployer un nouveau modèle une seule fois, surveiller son comportement et revenir en arrière sans intervenir sur chaque machine.

Les modèles locaux exigent une chaîne de distribution. Les équipes doivent gérer les variations matérielles, les limites de stockage, la compatibilité des firmwares, le suivi des versions et les échecs lors de l’installation.

L’apprentissage à l’échelle de la flotte favorise aussi la centralisation. Lorsqu’un robot rencontre un colis, un outil ou une configuration de pièce inhabituels, un service partagé peut intégrer ce cas pour les autres machines.

L’entraînement relève encore plus clairement de l’infrastructure centralisée. NVIDIA décrit une architecture à trois ordinateurs qui sépare l’entraînement, la simulation et l’exécution embarquée.

Dans ce modèle, les systèmes DGX entraînent l’IA, les serveurs génèrent de l’expérience simulée et les ordinateurs Jetson exécutent des capacités sélectionnées au sein des robots. L’architecture répartit le travail selon ses exigences physiques et computationnelles.

Cette répartition montre pourquoi un récit fondé uniquement sur l’edge reste incomplet. L’intelligence robotique dépend d’une chaîne qui crée, teste, déploie, observe et met à jour les modèles.

Le datacenter n’est pas simplement un cerveau distant répondant à des requêtes en direct. C’est aussi l’atelier où le cerveau local d’un robot est construit et amélioré.

L’inférence distante reste précieuse au sein de cette chaîne. Un robot peut demander à un modèle plus grand d’interpréter une instruction inconnue, de comparer plusieurs plans ou d’interroger une vaste base de connaissances techniques.

La réponse n’a pas besoin de contrôler directement un moteur. Elle peut fournir un plan que les systèmes locaux valident et exécutent sous les contraintes de sécurité actuelles.

Cette distinction protège le robot contre les commandes tardives ou inappropriées. Elle préserve aussi l’accès à des capacités qui ne peuvent pas être embarquées.

L’architecture gagnante sépare les réflexes du raisonnement

La réponse pratique est une hiérarchie : les systèmes locaux contrôlent le comportement immédiat, tandis que les systèmes distants prennent en charge le raisonnement coûteux et l’apprentissage à l’échelle de la flotte.

Les développeurs utilisent déjà le contrôle hiérarchique en robotique. Des composants rapides gèrent la stabilité et le mouvement, tandis que des composants plus lents choisissent les objectifs et les séquences.

L’IA générative étend cette structure plutôt que de la remplacer. Un modèle VLA peut relier les instructions aux actions, mais il continue de fonctionner aux côtés de contrôleurs, de moniteurs de sécurité, de systèmes de perception et de planificateurs.

La frontière la plus sûre suit l’urgence. Les calculs soumis à des délais stricts restent locaux. Les tâches qui tolèrent un délai peuvent être transférées vers un datacenter lorsque le traitement distant offre de meilleures capacités.

Un robot de livraison fournit un exemple utile. Les systèmes locaux doivent détecter les piétons, suivre le trottoir, s’arrêter devant les obstacles et maintenir l’équilibre sans connexion Internet.

Un système distant peut interpréter une nouvelle instruction de livraison, réorganiser un itinéraire ou évaluer l’entrée d’un bâtiment inconnu. Le robot peut ensuite vérifier le plan proposé au regard des conditions locales.

Les robots industriels présentent une répartition similaire. Le traitement embarqué peut inspecter des pièces et corriger les mouvements pendant l’assemblage. Un service central peut analyser les tendances de production dans plusieurs sites.

Les humanoïdes rendent cette frontière plus complexe, car leurs tâches sont moins prévisibles. Ils ont besoin d’un contrôle rapide de l’ensemble du corps, mais les utilisateurs peuvent leur demander d’exécuter des séquences longues et inédites.

La recherche Gemini Robotics initiale de Google décrit des modèles conçus pour se généraliser à différentes tâches et formes robotiques. Cette généralisation est importante, mais une évaluation en laboratoire ne peut pas couvrir toutes les conditions de déploiement.

Une architecture hybride permet l’escalade. Lorsque la confiance tombe sous un seuil, le robot peut s’arrêter, demander de l’aide ou transmettre un contexte sélectionné à un modèle distant plus puissant.

La confiance seule ne suffit pas. Les modèles appris peuvent rester confiants tout en se trompant, de sorte que les systèmes ont également besoin de limites opérationnelles explicites et de contrôles indépendants.

Le service distant devrait renvoyer des intentions structurées plutôt que des commandes d’actionneurs sans restriction. Par exemple, il pourrait proposer comme objectif « placer le conteneur bleu sur l’étagère trois ».

Le logiciel de planification local peut rejeter cet objectif si l’étagère est bloquée, si l’objet est instable ou si une personne entre dans la zone de travail.

Cette conception transforme le datacenter en consultant plutôt qu’en marionnettiste. Elle préserve une intelligence centralisée sans intégrer la fiabilité du réseau dans chaque boucle de contrôle.

L’acheminement des charges de travail devient une capacité produit centrale. Le système doit déterminer quel modèle peut résoudre chaque demande dans les limites de temps, d’énergie, de confidentialité et de sécurité qui lui sont imparties.

Les demandes simples peuvent rester embarquées. Les demandes complexes peuvent utiliser l’inférence distante, tandis que les demandes sensibles peuvent exiger un traitement local même lorsque le résultat local est moins performant.

La mise en cache peut réduire les appels répétés au cloud. Un robot peut obtenir à distance des instructions pour une nouvelle tâche, puis stocker une politique compacte pour une utilisation future.

Les opérateurs de flottes peuvent également planifier des analyses non urgentes. Les journaux des tâches terminées peuvent être téléversés pendant des périodes sûres, ce qui permet aux modèles de datacenter d’identifier des défaillances sans affecter le comportement en direct.

Cette approche rappelle les architectures informatiques qui combinent des applications locales et des services cloud. La robotique augmente les enjeux, car le résultat modifie des objets physiques et des environnements partagés.

L’avantage de NVIDIA réside dans la fourniture des deux côtés de cette répartition. Ses accélérateurs de datacenter soutiennent le développement de modèles et l’inférence distante, tandis que Jetson exécute certaines charges de travail à la périphérie.

Cette position crée également une tension pour les clients. Une pile verticalement intégrée peut simplifier le développement, mais elle peut accroître la dépendance envers le matériel, les logiciels et les outils de modélisation d’un seul fournisseur.

Google aborde le problème par les modèles et les services cloud, tandis que les fabricants de robots contrôlent l’intégration finale du matériel. D’autres fabricants de puces peuvent rivaliser en offrant une consommation énergétique plus faible ou des options de déploiement plus ouvertes.

L’enjeu principal n’est pas de savoir quelle entreprise se proclame le cerveau du robot. Il s’agit de déterminer quelle pile déplace le travail à travers la hiérarchie sans compromettre la latence, la sécurité ou l’économie.

Ce que les affirmations sur l’IA embarquée ne montrent pas

Les spécifications des fournisseurs prouvent que davantage de calcul tient à l’intérieur des robots, mais elles ne démontrent pas une autonomie fiable dans des environnements non contrôlés.

Les chiffres de débit de pointe décrivent rarement l’ensemble d’un système déployé. Les robots réels doivent répartir leurs ressources entre caméras, capteurs, réseau, planification, journalisation et fonctions de sécurité.

La précision annoncée compte également. Les performances FP4 représentent des calculs à faible précision, mais certains modèles ou opérations nécessitent une précision supérieure. Leur débit effectif peut différer du chiffre mis en avant.

La capacité mémoire ne correspond pas non plus à la capacité de modèle réellement utilisable. Le système d’exploitation, les pipelines de perception, les caches et les applications concurrentes consomment une partie de l’espace disponible.

La chaleur peut réduire les performances soutenues. Un processeur peut atteindre brièvement son pic, puis ralentir lorsque le refroidissement ne peut pas évacuer suffisamment de chaleur d’un boîtier compact.

Les robots alimentés par batterie font face à un autre compromis. Davantage de raisonnement embarqué peut réduire la dépendance au réseau, mais l’utilisation constante d’accélérateurs peut raccourcir le temps de fonctionnement ou exiger une batterie plus grande.

La compression des modèles introduit ses propres risques. La quantification réduit le nombre de bits utilisés pour les poids du modèle, ce qui rend ce dernier plus petit et plus rapide.

Cependant, la compression peut dégrader les performances de manière inégale. Les objets rares, les détails visuels subtils ou les instructions inhabituelles peuvent être davantage affectés que les tâches courantes des benchmarks.

Les démonstrations en laboratoire opèrent généralement dans des ensembles de tâches contrôlés. Les déploiements commerciaux introduisent des reflets, de la poussière, du bruit, des objets endommagés, des espaces bondés et des utilisateurs qui formulent leurs demandes de manière imprévisible.

Un modèle généraliste peut tout de même échouer à la limite de sa distribution d’entraînement. La question clé n’est pas de savoir s’il a réussi une démonstration soigneusement mise en scène.

Les opérateurs ont besoin de taux de défaillance sur de longs déploiements. Ils ont également besoin de données sur le comportement de récupération, la fréquence des interventions et les performances une fois les températures matérielles stabilisées.

L’inférence distante présente des lacunes comparables. Un modèle plus grand peut générer un meilleur plan tout en restant vulnérable à des informations de capteurs obsolètes ou à des instructions ambiguës.

Les statistiques de disponibilité du cloud ne reflètent pas non plus la qualité de connexion de chaque robot. Un service peut rester opérationnel alors qu’une machine perd sa couverture locale dans un ascenseur ou une installation aux murs métalliques.

La sécurité a deux facettes. Le traitement local réduit la transmission de données, mais placer des modèles précieux et des données opérationnelles sur un appareil crée une cible pour les attaques physiques.

Des attaquants peuvent voler un robot, inspecter son stockage ou exploiter un service local non corrigé. Les systèmes centralisés sont plus faciles à mettre à jour, bien qu’une seule compromission puisse affecter une flotte plus importante.

Les systèmes hybrides héritent des deux surfaces d’attaque. Ils nécessitent une authentification des appareils, des communications chiffrées, des mises à jour de modèles signées, des contrôles d’accès et des règles claires pour le fonctionnement hors ligne.

La dépendance aux fournisseurs mérite également un examen attentif. Une entreprise de robotique peut optimiser ses modèles autour d’un accélérateur, d’un environnement d’exécution et d’une chaîne d’outils de déploiement uniques.

Changer de fournisseur peut alors nécessiter une conversion des modèles, de nouveaux tests de performance et une nouvelle validation de sécurité. Ces coûts peuvent perdurer pendant toute la vie commerciale d’un robot.

NVIDIA indique que sa pile d’IA physique relie Jetson Thor au logiciel de robotique Isaac et à des outils associés de traitement des capteurs. Les clients doivent décider si cette intégration l’emporte sur le coût de cette dépendance.

Les publications embarquées de Google DeepMind soulèvent une autre incertitude : l’accès. Les programmes précoces ou réservés à des testeurs de confiance peuvent démontrer une orientation technique sans démontrer une disponibilité étendue en production.

Ni un matériel impressionnant ni un VLA performant ne résolvent la question de la responsabilité. Lorsqu’un robot hybride échoue, les enquêteurs doivent déterminer si l’erreur provient de l’appareil, du réseau, du modèle distant ou de la politique d’acheminement.

Ce défi de diagnostic façonnera l’assurance, les achats et la réglementation. Les acheteurs exigeront des journaux capables de reconstituer ce que chaque composant a observé et décidé.

Les déploiements les plus solides ne masqueront pas cette complexité derrière un score d’autonomie unique. Ils mesureront séparément le comportement local, l’escalade vers le cloud et l’intervention humaine.

Trois signaux révéleront où les robots pensent réellement

La prochaine étape sera déterminée par le comportement déployé, et non par une nouvelle série d’annonces sur les performances de calcul de pointe.

Le premier signal est la part des tâches robotiques effectuées sans inférence distante. Les fournisseurs devraient indiquer la fréquence à laquelle les machines escaladent, la durée de ces escalades et ce qui se produit lors d’une déconnexion.

Une hausse du taux d’exécution locale renforcerait l’argument en faveur de l’inférence robotique de NVIDIA et d’autres plateformes edge. Elle montrerait que les systèmes embarqués peuvent gérer plus que des réflexes d’urgence.

Cependant, cette métrique nécessite une définition stable des tâches. Un robot qui traite localement des missions plus simples ne surpasse pas nécessairement un autre robot qui envoie des problèmes plus difficiles au cloud.

Le deuxième signal est la performance soutenue dans des limites réelles d’énergie et de chaleur. Les acheteurs ont besoin de résultats provenant de robots complets fonctionnant durant de longues périodes, et non de processeurs isolés exécutant des tests courts.

Si Jetson Thor et les systèmes concurrents maintiennent plusieurs modèles sans pénalités inacceptables de chaleur ou de batterie, davantage de planification migrera vers les machines. Une limitation persistante des performances préserverait un rôle plus important pour le cloud.

Le troisième signal est la conception des architectures de flottes en production. Il faut observer si les grands fabricants de robots présentent le fonctionnement local d’abord, l’escalade distante et un comportement de repli auditable comme des caractéristiques explicites de leurs produits.

Une hiérarchie claire validerait la thèse hybride. Un système qui dépend discrètement d’une connectivité constante montrerait que son intelligence la plus importante vit encore ailleurs.

Les fournisseurs de datacenters ont également des raisons de soutenir cette hiérarchie. Ils peuvent vendre du raisonnement à plus forte valeur, de l’analytique de flotte, de la simulation et de l’entraînement sans traiter chaque image de capteur.

Les fabricants de puces edge bénéficient de l’expansion des charges de travail locales. Les fabricants de robots bénéficient de la possibilité de choisir, pour chaque tâche, le lieu d’exécution sûr le moins coûteux.

Les clients devraient poser des questions directes aux fournisseurs avant de choisir une plateforme. Quelles fonctions survivent à une panne réseau ? Quelles données quittent la machine ? Quel modèle produit chaque décision ?

Ils devraient aussi demander comment le robot rejette les instructions cloud obsolètes. Un plan distant créé quelques secondes auparavant peut ne plus correspondre à la scène actuelle.

Pour les développeurs, la tâche de conception essentielle ne consiste plus à choisir un seul emplacement d’inférence. Il s’agit de construire un routeur qui traite la latence, la confiance, la confidentialité et la sécurité comme des contraintes de premier ordre.

Les travailleurs du savoir rencontreront la même décision par l’intermédiaire de robots de bureau, d’appareils autonomes et de systèmes d’IA qui observent des espaces physiques. L’emplacement des données façonnera la confiance autant que la capacité des modèles.

L’inférence robotique de NVIDIA rend une architecture locale d’abord plus pratique, mais elle ne tranche pas le débat plus large. Les datacenters fournissent toujours les plus grands modèles et la boucle d’apprentissage partagée.

La meilleure question n’est donc pas de savoir où pense un robot. Il faut demander quelles pensées doivent se produire immédiatement, lesquelles exigent une plus grande échelle, et qui demeure responsable lorsque les deux ne sont pas d’accord.