Les agents IA de MathWorks face à l’épreuve de confiance de Simulink

MathWorks a intégré des agents IA à des flux de travail Simulink concrets, offrant aux ingénieurs une nouvelle porte d’entrée vers une plateforme réputée pour sa courbe d’apprentissage exigeante. L’histoire a atteint Google News sous l’angle d’une adoption plus simple. Pourtant, le véritable enjeu n’est pas de savoir si un agent peut manipuler un modèle. Il s’agit de déterminer si les équipes d’ingénierie peuvent faire confiance aux modifications apportées par l’agent, les examiner et les vérifier.

Le Simulink Agentic Toolkit relie des agents de codage à des sessions MATLAB et Simulink actives. Un agent peut inspecter l’architecture d’un modèle, modifier des blocs, exécuter des simulations et lancer des tests comportementaux via des outils structurés. L’assistance par IA dépasse ainsi les explications pour passer à des actions qui influencent une conception d’ingénierie.

MathWorks remet donc en question le parcours manuel, piloté par des spécialistes, qui a défini le développement basé sur les modèles pendant des décennies. L’entreprise ne retire pas les ingénieurs du processus. Elle cherche à faire évoluer leur travail : plutôt que d’utiliser chaque outil, ils examinent les plans, les hypothèses, les modifications du modèle et les preuves de test.

Cette distinction est importante. Une interface conversationnelle peut rendre Simulink plus accessible, mais un accès facilité ne garantit pas qu’un modèle généré soit correct. Les organisations d’ingénierie ont toujours besoin d’exigences, de traçabilité, de preuves issues des simulations et d’une approbation humaine avant de faire confiance à un résultat automatisé.

Ce que MathWorks a réellement changé

Le changement majeur est l’accès structuré aux modèles, et non un chatbot supplémentaire placé à côté d’une application d’ingénierie.

MathWorks a publié le Simulink Agentic Toolkit en tant que projet GitHub open source en avril 2026. La boîte à outils relie des agents de codage IA compatibles à Simulink via le Model Context Protocol, ou MCP. MCP est une interface standard qui permet à un système d’IA d’appeler des outils externes et de récupérer un contexte structuré.

La boîte à outils s’appuie sur le MATLAB MCP Server. Ce serveur connecte un agent IA à une session MATLAB active, tandis que la couche Simulink ajoute des capacités propres aux modèles. L’agent reçoit un accès structuré à l’architecture, au flux des signaux, aux paramètres et au comportement de simulation.

Selon la présentation de la boîte à outils, les ingénieurs peuvent utiliser Claude Code, GitHub Copilot, OpenAI Codex, Gemini CLI ou Sourcegraph Amp. Le système n’est lié à aucun fournisseur de modèles particulier. Toutefois, l’agent sélectionné doit prendre en charge MCP et le format d’instructions de la boîte à outils.

La boîte à outils expose sept outils conçus pour cet usage :

• model_overview résume un modèle et sa hiérarchie.

• model_read récupère les blocs, les connexions et la structure du modèle.

• model_edit apporte des modifications structurelles contrôlées.

• model_check identifie les problèmes structurels.

• model_query_params récupère des paramètres sélectionnés.

• model_resolve_params résout les variables depuis les espaces de travail du modèle.

• model_test exécute des tests comportementaux lorsque Simulink Test est disponible.

Cette frontière entre outils est importante, car les modèles de langage fonctionnent généralement mieux avec du texte. Un modèle Simulink est un système graphique et hiérarchique qui contient des blocs, des signaux, des paramètres et un comportement d’exécution. Convertir l’ensemble en texte non structuré consommerait du contexte et masquerait les relations.

La boîte à outils permet plutôt à un agent de demander les informations précises du modèle nécessaires à une tâche. MathWorks indique que cette approche permet au système de travailler avec des modèles plus volumineux, car l’agent ne lit pas chaque composant simultanément.

Les compétences métier ajoutent une autre couche. Il s’agit de flux de travail écrits qui indiquent à l’agent comment aborder des activités telles que la rédaction d’exigences, la construction de modèles, la simulation, les tests et le signalement de bogues. Les outils fournissent l’accès, tandis que les compétences encadrent la manière dont cet accès doit être utilisé.

Cela diffère de Simulink Copilot. Copilot est l’assistant conversationnel intégré de MathWorks, destiné à expliquer les modèles, trouver des composants, diagnostiquer des erreurs et recommander des modifications. Il peut également exécuter des tâches prédéfinies de Process Advisor.

MathWorks indique dans sa FAQ Copilot que la version R2026a ne génère ni ne modifie de modèles Simulink. Elle fournit plutôt des conseils. L’Agentic Toolkit donne à un agent de codage externe les outils nécessaires pour créer et modifier des modèles.

Cette séparation peut dérouter les lecteurs arrivant depuis Google News. Copilot est un assistant hébergé par MathWorks au sein du produit. L’Agentic Toolkit est un pont extensible reliant des agents tiers pris en charge aux outils et flux de travail d’ingénierie.

Le bénéfice d’adoption rapporté vient de la combinaison d’instructions en langage naturel et d’opérations d’ingénierie exécutables. Un ingénieur peut décrire un objectif, examiner le plan proposé et laisser l’agent effectuer certaines étapes de mise en œuvre. L’ingénieur inspecte ensuite le modèle et les résultats des tests.

MathWorks a également simplifié l’installation depuis la version initiale. Son guide de configuration actuel utilise un installateur et une fonction de configuration MATLAB. Le processus configure le serveur, les fichiers de la boîte à outils, l’intégration de l’agent et les contrôles de validation.

Réduire les frictions d’installation renforce l’argument en faveur de l’adoption. Pourtant, l’installation n’est que le premier obstacle. Le défi le plus difficile commence lorsqu’un agent modifie un modèle qui influencera un comportement physique.

Pourquoi les agents IA abaissent la barrière d’adoption de Simulink

Les agents IA facilitent l’accès aux flux de travail spécialisés, car les utilisateurs peuvent commencer par un objectif d’ingénierie plutôt que par une séquence d’opérations dans l’interface.

Simulink prend en charge la conception basée sur les modèles, un processus dans lequel les équipes créent un modèle système exécutable avant de finaliser le matériel de production ou le logiciel embarqué. Les ingénieurs peuvent simuler le comportement, tester la logique de commande et générer du code à partir du modèle.

Cette approche est largement utilisée pour les systèmes où les logiciels interagissent avec des composants physiques. Parmi les exemples figurent les commandes de véhicules, l’automatisation industrielle, la robotique, les systèmes aérospatiaux et les équipements énergétiques. Ces projets exigent souvent une expertise en commande, en logiciel, en modélisation physique et en vérification.

Cette étendue crée une barrière à l’adoption. Un nouvel utilisateur doit comprendre le problème d’ingénierie et apprendre comment Simulink le représente. Il doit également trouver des blocs adaptés, configurer des paramètres, organiser des sous-systèmes, lancer des simulations et interpréter les échecs.

L’automatisation traditionnelle réduit certains efforts grâce aux scripts MATLAB et aux API des produits. Cependant, les scripts exigent que les utilisateurs connaissent les fonctions disponibles et expriment chaque opération avec précision. Un script devient aussi un artefact supplémentaire que les équipes doivent maintenir.

Un agent IA change le point de départ. L’utilisateur peut décrire un système souhaité, demander un plan de mise en œuvre et affiner ce plan avant d’autoriser les modifications du modèle. L’agent traduit ensuite l’intention approuvée en appels d’outils.

Un ingénieur de MathWorks a illustré ce processus avec un modèle thermique de frein après la publication de la boîte à outils. L’agent a d’abord produit des plans d’architecture et de mise en œuvre. Ces plans décrivaient les hypothèses du système, les limites des composants, les équations, les paramètres et les tests proposés.

Après plusieurs itérations de planification, l’agent a créé un modèle Simulink comprenant des sous-systèmes de véhicule et de freinage. Il a également proposé des tests de composants et des scénarios de simulation complets. La présentation d’ingénierie décrit l’exemple comme un flux de travail piloté par la revue plutôt que comme une génération en une seule étape.

Ce schéma peut aider les ingénieurs expérimentés autant que les débutants. Les utilisateurs chevronnés savent souvent ce que le système doit faire, mais passent tout de même du temps à assembler la structure du modèle, mettre à jour la documentation, reproduire des défauts ou configurer des tests répétitifs.

Un agent peut prendre en charge ces étapes opérationnelles tandis que l’ingénieur se concentre sur les hypothèses et les critères d’acceptation. Cela rappelle l’effet des agents de codage sur le développement logiciel, même si les modèles graphiques d’ingénierie imposent des exigences de vérification différentes.

La boîte à outils crée également un moyen de comprendre les modèles existants. Les projets Simulink hérités peuvent contenir des sous-systèmes imbriqués, des bibliothèques personnalisées, des variables d’espace de travail et des années de décisions de conception. Les ingénieurs qui rejoignent de tels projets peuvent consacrer beaucoup de temps à suivre les signaux et à localiser les composants pertinents.

Les requêtes structurées sur le modèle permettent à un agent de résumer une hiérarchie ou de récupérer des relations sélectionnées. Un utilisateur peut demander où un signal prend naissance, quels blocs dépendent d’un paramètre ou comment un sous-système s’intègre dans l’architecture globale.

Cette capacité n’élimine pas la nécessité d’inspecter le modèle. Elle peut réduire le coût de l’identification des zones à examiner. Cet avantage devient particulièrement pertinent lorsque des responsables expérimentés de modèles quittent une équipe ou rejoignent un autre programme.

Le travail sur les exigences offre une autre voie d’adoption. Un agent peut rédiger des exigences à partir d’une spécification initiale et les relier aux éléments pertinents du modèle lorsque les produits MathWorks requis sont disponibles. Les liens de traçabilité indiquent quels composants de conception mettent en œuvre chaque exigence.

Pour les organisations qui évaluent Simulink, ces flux de travail assistés modifient le calcul de l’intégration. La plateforme requiert toujours des connaissances en ingénierie, mais moins de tâches commencent par la recherche d’un menu, d’une commande ou d’une API obscure.

Les lecteurs de Google News ne devraient pas interpréter cela comme une promesse de développement sans code. Le langage naturel devient une surface de contrôle supplémentaire, et non un remplacement des connaissances système. Les utilisateurs incapables d’identifier une hypothèse erronée auront du mal à examiner le plan d’un agent.

Le bénéfice le plus réaliste est donc une adoption assistée. Les agents IA peuvent raccourcir le chemin entre une question d’ingénierie et un artefact inspectable. Ils ne peuvent pas décider si cet artefact satisfait aux exigences de sécurité, de performance ou de réglementation.

Le véritable enjeu oppose l’automatisation au contrôle d’ingénierie

MathWorks doit démontrer que la rapidité portée par les agents peut coexister avec la discipline de revue attendue de la conception basée sur les modèles.

Un agent de codage généraliste est optimisé pour mener des tâches à bien. Un processus d’ingénierie est optimisé pour produire des preuves qu’un système se comporte correctement dans des conditions définies. Ces objectifs se recoupent, mais ils ne sont pas identiques.

Un agent peut créer un modèle plausible qui s’exécute sans erreur. Ce résultat peut néanmoins reposer sur de mauvaises hypothèses physiques, unités, réglages de solveur, conditions limites ou périodes d’échantillonnage. Une simulation réussie montre seulement ce qui s’est produit à l’intérieur du modèle spécifié.

La boîte à outils répond à cette tension en encourageant la planification avant la mise en œuvre. Pour les tâches complexes, un agent peut rédiger une spécification et demander à l’ingénieur de trancher les choix de conception avant de modifier le modèle. Il peut également proposer des tests qui capturent le comportement attendu.

Des points de contrôle humains apparaissent tout au long de la description produit de MathWorks. L’agent peut reproduire un problème, isoler une cause suspectée, créer un test et proposer une correction. L’ingénieur examine les conclusions avant d’approuver la modification.

Cette conception place l’ingénieur dans un rôle de supervision. Pourtant, la supervision ne fonctionne que lorsque les artefacts générés restent compréhensibles. Un long plan rempli de détails plausibles peut submerger les réviseurs au lieu de les aider.

La traçabilité devient ici cruciale. Les équipes doivent savoir quelle exigence a motivé un élément du modèle, quelle hypothèse a guidé un paramètre et quel test vérifie un comportement. Un agent qui produit des modifications sans préserver ces relations crée un travail de revue caché.

Le Model Context Protocol aide en imposant des interactions via des outils nommés. Une demande de modification d’un modèle se distingue d’une demande de lecture. Les organisations peuvent potentiellement observer ces appels et limiter les opérations qu’un agent est autorisé à exécuter.

Un accès structuré est plus sûr qu’un contrôle illimité de l’écran, mais il ne constitue pas un système de gouvernance complet. L’agent décide toujours quel outil appeler, quels paramètres fournir et comment interpréter le résultat.

La conception basée sur les modèles donne déjà à MathWorks un avantage dans cette compétition. Les modèles Simulink sont exécutables, et les équipes peuvent comparer le comportement simulé aux exigences. Les tests peuvent être relancés après des modifications, créant une boucle de retour que la génération ordinaire de documents n’offre pas.

Les agents IA peuvent exploiter cette boucle. Ils peuvent mettre en œuvre une modification, exécuter une simulation, examiner le résultat et réviser le modèle. Cette capacité distingue cette boîte à outils des assistants qui se contentent de générer du code suggéré ou des instructions écrites.

Cette même boucle introduit un risque d’automatisation. Un agent peut optimiser par rapport à un ensemble de tests incomplet et produire un modèle qui réussit les contrôles connus tout en échouant ailleurs. Les équipes logicielles connaissent ce problème lorsque du code généré passe les tests visibles mais viole des exigences non formulées.

Les équipes d’ingénierie doivent donc considérer la conception des tests comme faisant partie de la spécification. Les plages de fonctionnement importantes, les conditions de défaillance, le comportement temporel et les contraintes physiques doivent être explicitement couverts. L’agent ne doit pas définir seul l’intégralité de son périmètre d’évaluation.

Le choix du modèle d’IA influence également les résultats. La documentation de configuration de MathWorks indique que les capacités du modèle ont un impact significatif sur les flux de travail exigeants de construction et de modification. L’entreprise rapporte que les modèles plus légers étaient moins fiables et plus susceptibles de produire un travail incomplet ou incorrect.

Cela signifie que les performances de la boîte à outils ne sont pas une propriété fixe du produit. Les résultats dépendent de l’agent connecté, du modèle de langage sous-jacent, des instructions, du contexte du projet et de la qualité de la revue d’ingénierie.

Les organisations devront mettre en place des processus de qualification pour ces combinaisons. Un flux de travail accepté avec une version de modèle ne peut pas être automatiquement considéré comme fiable après que le fournisseur a modifié le comportement de ce modèle.

La boîte à outils prend actuellement en charge plusieurs grands agents de programmation, ce qui offre de la flexibilité aux acheteurs. Elle multiplie aussi les configurations que les équipes devront peut-être évaluer, documenter et gouverner.

Pour les utilisateurs attirés par Google News, c’est le renversement central. L’agent abaisse la barrière d’interface tout en renforçant l’importance d’une revue formelle. Une création de modèles plus facile rend la validation plus nécessaire, et non moins.

Ce que l’agent ne peut pas décider seul de manière fiable

La plus grande incertitude est de savoir si les équipes peuvent détecter des erreurs convaincantes avant que les modifications générées par l’agent n’entrent dans des travaux d’ingénierie aux conséquences importantes.

Les modèles de langage produisent des résultats probabilistes. MathWorks avertit explicitement que les réponses de Simulink Copilot peuvent varier lorsque les utilisateurs répètent la même question. Les agents de programmation externes introduisent une variabilité similaire, car leur planification et leurs choix d’outils dépendent du comportement du modèle.

Le raisonnement probabiliste peut aider à explorer des alternatives de conception. Il crée des difficultés lorsque les organisations attendent des procédures identiques et des décisions reproductibles. Les ingénieurs devront peut-être conserver les prompts, les plans, les appels d’outils, les versions de modèles et les résultats de tests dans un même dossier de revue.

L’agent ne dispose pas non plus d’une connaissance indépendante des hypothèses non exprimées d’un projet. Il ne peut pas déduire de manière fiable toutes les contraintes de sécurité, limites de fournisseurs, règles d’étalonnage ou obligations de certification à partir d’une demande partielle.

Prenons un contrôleur décrit uniquement par sa réponse souhaitée. Plusieurs implémentations peuvent satisfaire cette réponse en fonctionnement normal. Elles peuvent se comporter très différemment en cas de défaillance de capteur, de saturation, de gigue temporelle ou de conditions environnementales inattendues.

Un agent peut choisir une conception techniquement valide qui entre en conflit avec les conventions de l’équipe. Il peut placer la logique dans la mauvaise couche architecturale, dupliquer un composant réutilisable ou encoder des paramètres là où l’organisation attend un dictionnaire de données.

MathWorks utilise des skills pour guider ces choix. Les skills peuvent encoder des pratiques de conception basée sur les modèles et indiquer à l’agent de recueillir les exigences avant l’implémentation. Cependant, un flux de travail écrit ne peut pas refléter toutes les normes internes de chaque organisation.

Les équipes auront besoin d’instructions et de contrôles propres au projet. Elles pourront également avoir besoin de limites d’autorisation empêchant les agents de modifier des bibliothèques protégées, des interfaces partagées, des mécanismes de sécurité ou des configurations de production.

La gestion des données soulève une autre question. L’agent lit des informations sélectionnées du modèle et utilise, dans de nombreuses configurations courantes, un modèle de langage hébergé dans le cloud. Les organisations doivent évaluer quel contexte quitte le poste de travail et comment chaque fournisseur le stocke.

MathWorks indique que les données des utilisateurs finaux soumises à Simulink Copilot ne sont pas utilisées pour entraîner les modèles d’IA. Cette déclaration s’applique à Copilot. Un agent tiers connecté via la boîte à outils fonctionne selon les politiques de données et les contrôles d’entreprise de son propre fournisseur.

Cette distinction mérite un examen attentif lors des achats. La boîte à outils ouverte fournit l’intégration, mais elle ne crée pas un dispositif universel de confidentialité pour tous les agents pris en charge.

La qualité du contexte du modèle fixe également une limite pratique. Les grands programmes Simulink peuvent inclure des blocs personnalisés, des composants compilés, des données externes et des bibliothèques propres à l’organisation. Un agent qui ne lit qu’un contexte sélectionné peut manquer une dépendance qu’un relecteur humain considère comme évidente.

Lire l’intégralité du modèle créerait ses propres problèmes. Davantage de contexte augmente le coût de traitement et peut réduire la capacité d’un agent à se concentrer sur les détails pertinents. La conception d’outils sélectifs de MathWorks est un mécanisme raisonnable, mais la sélection elle-même devient une partie du risque.

Les chercheurs explorent également des approches alternatives. SimuAgent utilise une représentation compacte destinée à faciliter le traitement des structures Simulink par les modèles de langage. SimuGen combine des informations visuelles et sectorielles pour construire des diagrammes de blocs.

Ces systèmes de recherche indiquent que la représentation reste un problème ouvert. Aucun benchmark unique ne permet actuellement à un acheteur en ingénierie de savoir avec quelle fiabilité différents agents peuvent modifier des modèles industriels complexes.

La concurrence ajoute de la pression. JuliaHub positionne son environnement Dyad comme une alternative orientée IA pour la conception de systèmes physiques. Une comparaison sectorielle décrit l’entreprise comme contestant Simulink avec une plateforme de modélisation construite autour de Julia et de flux de travail agentiques.

JuliaHub peut concevoir autour de l’IA dès une étape plus précoce du produit. MathWorks apporte une vaste base installée, des flux de travail d’ingénierie matures et de nombreux produits sectoriels. Son défi consiste à ajouter un comportement agentique sans affaiblir les contrôles dont dépendent déjà ses clients.

Cette concurrence ne se résume pas à une entreprise contre une autre. Elle met à l’épreuve deux voies d’adoption. L’une ajoute des agents à un système de modélisation établi. L’autre construit des environnements plus récents où l’assistance IA est centrale dans l’expérience utilisateur.

Les équipes Simulink établies peuvent préférer un agent qui fonctionne avec les modèles, tests et connaissances organisationnelles existants. Les nouveaux projets peuvent se demander si une plateforme orientée IA offre moins de complexité historique.

Aucune de ces voies n’échappe à la vérification. Les voitures, avions, robots et machines industrielles réagissent à des conditions physiques, pas à un texte persuasif. L’explication d’un agent n’a aucune valeur d’ingénierie si la conception résultante ne résiste pas à l’inspection et aux tests.

Les équipes qui adoptent ces systèmes devraient constituer un registre consultable des exigences, hypothèses, décisions et preuves de validation. Une base de connaissances d’ingénierie structurée peut aider les relecteurs à retrouver le contexte entourant une modification de l’agent.

Le risque immédiat n’est pas que les agents remplacent les ingénieurs en contrôle-commande. C’est que les équipes acceptent le travail généré plus vite qu’elles n’améliorent leur capacité de revue. Ce déséquilibre transformerait une aide à l’adoption en source de dette technique.

Trois signaux à surveiller après l’attention de Google News

La valeur de la boîte à outils deviendra plus claire à travers des résultats de projets vérifiés, des contrôles de gouvernance renforcés et les réactions de la concurrence.

Le premier signal est constitué par les preuves issues de véritables programmes d’ingénierie. MathWorks a publié des démonstrations, et des utilisateurs ont partagé des expérimentations. Les acheteurs ont désormais besoin de résultats reproductibles sur des projets plus vastes dotés de modèles existants, de bibliothèques personnalisées et d’exigences formelles de vérification.

Des preuves utiles compareraient les flux de travail assistés par agent et conventionnels sur une même tâche. Les équipes devraient mesurer le temps de planification, l’effort d’implémentation, l’effort de revue, les défauts détectés et les régressions introduites.

Un premier brouillon plus rapide ne suffit pas. Le résultat pertinent est le temps total nécessaire pour parvenir à une modification acceptée et vérifiée. Si la revue et la correction absorbent le temps gagné lors de l’implémentation, l’argument en faveur de l’adoption s’affaiblit.

Les preuves devraient aussi identifier l’agent et la version de modèle utilisés. MathWorks note déjà que les modèles plus puissants obtiennent de meilleurs résultats sur les flux de travail exigeants. Les résultats dépourvus de détails de configuration seront difficiles à reproduire.

Le deuxième signal est l’évolution de la gouvernance. Les organisations ont besoin de contrôles sur les autorisations d’outils, les approbations, les pistes d’audit, les mouvements de données, les versions de modèles et les preuves de test.

L’architecture MCP de la boîte à outils jette les bases de ces contrôles, car les actions passent par des outils définis. Les futures versions pourront renforcer l’autorisation autour des opérations sensibles et faciliter l’inspection de l’activité des outils.

Les équipes devraient surveiller si MathWorks ajoute des orientations plus claires pour les entreprises concernant la qualification des agents pris en charge. Les acheteurs voudront aussi des modèles pour isoler les projets, protéger les bibliothèques partagées et examiner les modifications de modèles avant leur enregistrement.

La gouvernance des données restera une partie de ce signal. Chaque agent connecté peut avoir des politiques de conservation et des options de déploiement différentes. Les organisations ont besoin de réponses spécifiques à chaque configuration, plutôt que d’assurances générales sur la confidentialité de l’IA.

Le troisième signal est la manière dont les concurrents réagissent. JuliaHub a déjà présenté l’ingénierie agentique comme une occasion de défier les plateformes de simulation établies. D’autres fournisseurs de logiciels d’ingénierie assistée par ordinateur ajoutent de l’automatisation conversationnelle et de type agent aux flux de travail de simulation.

Une réponse concurrentielle combinant la planification en langage naturel et la vérification exécutable renforcerait l’orientation de MathWorks. Un rival offrant une adoption plus facile avec des preuves de validation plus claires affaiblirait son avantage.

MathWorks continue de présenter des flux de travail agentiques sur l’ensemble du cycle de développement. Une session sur les systèmes de contrôle programmée décrit un agent générant des exigences, concevant un contrôleur, exécutant des simulations, réalisant des tests logiciels et processeurs, puis générant du code embarqué.

Ce scénario de bout en bout est ambitieux. Il met aussi en lumière la question centrale à chaque étape : quelles décisions appartiennent à l’agent et lesquelles exigent un ingénieur responsable ?

La visibilité sur Google News peut présenter la boîte à outils à des personnes qui considéraient auparavant Simulink comme difficile ou très spécialisé. L’adoption durable dépendra de ce qui se passe après cette première rencontre.

Les responsables de l’ingénierie devraient commencer par des tâches limitées. L’explication de modèles, la reproduction de problèmes, l’inspection de paramètres et la rédaction de tests offrent des points d’entrée utiles. Les équipes peuvent ensuite comparer la sortie de l’agent à des résultats connus avant d’autoriser des modifications plus étendues.

Elles devraient exiger des plans avant l’implémentation et des tests avant l’acceptation. Elles devraient conserver les prompts, hypothèses, différences entre modèles et preuves de simulation à l’appui de chaque modification approuvée.

Surtout, elles devraient mesurer le coût de la revue. Les agents IA ne faciliteront l’adoption de Simulink que si les ingénieurs peuvent valider leur travail sans créer un nouveau goulot d’étranglement.

Les prochains mois devraient révéler si les utilisateurs passent des démonstrations à des flux de travail de production gouvernés. Surveillez les résultats de projets documentés, les contrôles d’autorisation et les fonctionnalités de vérification concurrentielle. Ces signaux indiqueront si le moment Google News marque une adoption plus large ou simplement un intérêt précoce pour une interface prometteuse.