La couche manquante de l’IA pour l’ingénierie est l’accès aux données basé sur les rôles

Le contenu de cette page a été traduit automatiquement par un service tiers.

Le marché se dirige peut-être vers la mauvaise ligne d’arrivée

À l’heure actuelle, une grande partie du secteur semble se concentrer sur une question simple : à quelle vitesse pouvons-nous créer des agents ?

Je comprends l’attrait. Les agents sont concrets. Ils se prêtent bien aux démonstrations et permettent de rendre les progrès facilement visibles. Mais je ne suis pas certain que la vitesse soit le premier problème à résoudre, surtout dans le domaine de l’ingénierie. Nous nous précipitons peut-être pour construire la couche des agents avant que certaines des fondations plus complexes sur lesquelles elle repose soient prêtes.

L’ingénierie n’a pas besoin d’autonomie simplement parce que l’autonomie est possible. Elle a besoin d’une IA capable de participer de manière fiable au véritable travail d’ingénierie, où les données produit, les processus de modification, la traçabilité, les autorisations et les méthodes de travail propres à chaque client ont tous leur importance. Un agent peut sembler impressionnant lors d’une démonstration et pourtant montrer ses limites lorsqu’il est confronté à cette réalité.

Plus j’observe l’évolution de ce marché, plus je pense que nous nous concentrons sur la partie visible du problème. Ce qui manque à l’IA pour l’ingénierie, ce n’est pas une nouvelle version de modèle ni une collection plus importante d’agents. C’est un accès aux données et au contexte dont les personnes ont réellement besoin pour faire leur travail, en fonction de leur rôle.

L’ingénierie ne manque pas d’intelligence

La plupart des organisations d’ingénierie disposent déjà d’une grande expertise. L’accès au contexte est une autre question.

Une exigence peut se trouver dans un système tandis que la structure produit réside dans un autre. Les dossiers de modification, l’historique qualité, les contraintes de fabrication, les informations fournisseurs, les retours du terrain et les décisions relatives aux programmes peuvent tous être dispersés tout au long du cycle de vie, souvent avec des règles différentes déterminant qui peut les consulter ou les modifier.

C’est dans cet environnement que l’IA doit fonctionner. Et c’est l’une des raisons pour lesquelles une IA générique peut avoir du mal à offrir le niveau de fiabilité attendu par les équipes d’ingénierie.

La question n’est donc pas de savoir si un système d’IA peut produire une réponse qui semble intelligente. Peut-il trouver le bon contexte du cycle de vie pour cette personne, pour cette tâche, à cet instant précis ? Peut-il le faire avec les autorisations appropriées ? Et l’ingénieur peut-il revenir à la source et comprendre d’où provient la réponse ?

Ce sont des critères beaucoup plus pratiques. Sans eux, l’assistance devient rapidement une nouvelle source de bruit.

La multiplication des agents créera un autre problème

Nous approchons également d’un point où le nombre même d’agents pourrait devenir une partie du problème.

Les ingénieurs n’ont pas un temps illimité pour évaluer de nouveaux outils. La plupart des équipes travaillent déjà dans un environnement technologique complexe, et leur demander d’évaluer individuellement un flux constant de nouveaux agents n’est pas réaliste. À mesure que leur nombre augmente, le défi évolue. Trouver un agent devient facile. Déterminer lesquels méritent réellement notre attention devient plus difficile.

Je pense donc que la sélection deviendra au moins aussi importante que l’adoption.

Les équipes d’ingénierie auront besoin d’un moyen de distinguer les outils qui améliorent véritablement l’accès à des informations d’ingénierie fiables de ceux qui ne font qu’ajouter une interface supplémentaire. Cette distinction ne sera pas toujours évidente. Elle se révélera dans le travail lui-même, dans la qualité du contexte auquel un agent peut accéder, dans les contrôles qui encadrent cet accès et dans la capacité de ses résultats à aider quelqu’un à prendre une meilleure décision.

Dans un tel marché, le discernement compte davantage que l’enthousiasme.

Un rôle n’est pas une fonctionnalité, il fait partie de l’architecture

Un élément se perd souvent dans les discussions générales sur l’IA d’entreprise : à quel point le travail d’ingénierie dépend réellement des rôles.

Prenons un même problème produit. Un ingénieur systèmes peut vouloir comprendre les exigences qui en sont à l’origine. Un ingénieur de fabrication cherchera plus probablement à savoir quelles en seront les conséquences en aval, dans l’atelier. L’équipe qualité devra peut-être relier le problème à une modification particulière ou à un événement antérieur. Un responsable de programme pourrait examiner ce même problème sous l’angle du risque lié aux délais ou de son impact sur le client.

Même produit. Même problème sous-jacent. Des questions très différentes.

Et surtout, ces personnes ne devraient pas nécessairement avoir accès exactement aux mêmes informations.

C’est pourquoi je considère le rôle comme un élément architectural, et non comme une fonctionnalité de personnalisation. Il influence la pertinence, les autorisations, les éléments de preuve et, en fin de compte, la capacité d’une personne à faire confiance à ce que l’IA lui indique.

Pour que l’IA fonctionne dans l’ingénierie, elle doit respecter ces limites. Donner à tout le monde un accès plus rapide à un contexte incomplet ou inapproprié ne rend pas une organisation plus intelligente. Cela permet simplement à des informations partielles de circuler plus vite.

La véritable opportunité n’est pas de produire des agents en masse

C’est également là que, selon moi, le marché doit repenser sa définition de la réussite.

Créer un vaste catalogue d’agents génériques et laisser les clients leur trouver des utilisations n’est pas particulièrement convaincant. Une question plus intéressante consiste à déterminer où l’IA peut faire une différence significative dans le véritable travail d’ingénierie, puis comment cette capacité doit être adaptée aux processus, aux données et à la gouvernance du client.

Il n’existe pas un environnement d’ingénierie standard unique pour lequel concevoir l’IA.

Les structures produit varient. Les processus de modification évoluent. Les systèmes s’accumulent au fil des années. Les modèles de données portent l’histoire d’innombrables décisions commerciales et d’ingénierie. Deux entreprises peuvent utiliser la même plateforme de base de façons remarquablement différentes.

L’IA ne fait pas disparaître ces différences. D’une certaine manière, elle les met en évidence.

C’est pourquoi je ne considère pas les agents comme des produits universels. Ils sont plus utiles en tant que preuves concrètes : des exemples pratiques de ce que l’IA peut accomplir dans un véritable workflow, tout en sachant que l’expérience devra s’adapter à l’organisation qui l’utilise.

C’est ici que la stratégie de plateforme commence à compter

Cela a des implications pour la stratégie de plateforme.

Les entreprises les mieux placées ne seront peut-être pas celles qui racontent l’histoire la plus ambitieuse autour de l’IA. Je pense que l’avantage ira aux plateformes qui savent déjà fonctionner dans des environnements d’ingénierie très spécifiques, façonnés par les besoins des clients, et qui peuvent apporter cette même capacité d’adaptation à l’IA.

Pensez à ce que les clients attendent déjà d’une plateforme configurable. Elle doit pouvoir prendre en charge des cycles de vie produit complexes, différents processus, des modèles de données qui évoluent et la manière dont une organisation particulière fonctionne réellement. Pourquoi l’IA devrait-elle être différente ?

Elle ne devrait pas arriver sous la forme d’une couche rigide placée au-dessus de tout le reste. Elle devrait fonctionner au sein de cet environnement, en utilisant des agents là où ils sont pertinents afin de transformer un contexte de cycle de vie gouverné en informations sur lesquelles les personnes peuvent agir.

Vu sous cet angle, l’agent lui-même devient moins intéressant. Ce qui compte, c’est ce à quoi l’agent peut accéder de manière responsable et ce qu’il aide quelqu’un à accomplir.

Pour les fournisseurs de logiciels d’ingénierie, je pense qu’il s’agit d’une position beaucoup plus durable. Elle déplace la conversation de la manière dont l’IA est proposée vers les questions que les clients finiront de toute façon par poser : cela nous a-t-il aidés à prendre une meilleure décision ? Avons-nous réellement gagné du temps ? Pouvons-nous lui faire confiance ? Cela fonctionne-t-il vraiment dans notre environnement ?

La stratégie de continuité numérique est mise à l’épreuve, et non remplacée

L’IA soumet également des années de stratégie autour de la continuité numérique à un test très concret.

Depuis longtemps, les discussions sur la continuité numérique portent sur la connexion : relier les informations entre les domaines, les équipes, les systèmes et les différentes étapes du cycle de vie. L’IA soulève la question suivante. Une fois ces informations connectées, pouvez-vous réellement les utiliser lorsqu’une décision doit être prise ?

C’est là que les choses deviennent intéressantes.

Un ingénieur peut-il faire apparaître les informations pertinentes pour son rôle sans contourner la gouvernance ? Peut-il remonter d’une réponse générée par l’IA jusqu’à l’enregistrement sous-jacent ? Le contexte du cycle de vie peut-il circuler suffisamment rapidement pour soutenir la décision tout en préservant son intégrité ?

Si la réponse est non, nous ne devons pas supposer que le problème vient de la couche d’IA. L’IA peut simplement révéler des faiblesses qui existaient déjà dans la stratégie de données sous-jacente.

C’est pourquoi je considère l’IA et la continuité numérique comme deux problématiques liées. L’IA pousse les systèmes de gestion du cycle de vie à faire davantage que stocker et gouverner les informations. Ces informations doivent désormais devenir utilisables au moment précis où quelqu’un en a besoin.

C’est une exigence plus difficile, et probablement plus utile.

Les limites passent avant l’autonomie

L’autonomie tend à dominer les discussions sur l’IA parce qu’il s’agit d’une destination facile à imaginer. Je ne pense pas que l’ingénierie puisse commencer par là.

Avant qu’une organisation n’accorde à l’IA davantage de liberté d’action, elle doit savoir où se trouvent les limites. Quel rôle est concerné ? Quel contexte le système devrait-il pouvoir utiliser ? Quelles autorisations s’appliquent ? Qu’est-ce qui doit être traçable ?

Et lorsqu’un ingénieur remet une réponse en question, le système doit être capable de montrer comment il y est arrivé.

Cela peut sembler moins ambitieux que des agents d’ingénierie entièrement autonomes. Je dirais que c’est tout le contraire. Construire un système d’IA capable de fonctionner de manière fiable dans les contraintes du véritable travail d’ingénierie est une réalisation bien plus significative que d’en construire un qui semble autonome jusqu’au moment où quelqu’un lui demande de justifier une décision.

La fiabilité doit précéder l’indépendance.

Commencez par la valeur propre au client, et non par le nombre d’agents

Je m’attends à voir apparaître beaucoup plus d’agents d’ingénierie au cours des 12 à 24 prochains mois. Certains résoudront de véritables problèmes. D’autres seront difficiles à distinguer les uns des autres une fois l’effet de nouveauté dissipé.

Les responsables de l’ingénierie n’ont pas besoin de tous les suivre.

Un meilleur point de départ consiste à examiner l’environnement dont ils disposent déjà. Où les personnes perdent-elles du temps parce qu’elles ne parviennent pas à accéder aux bonnes informations ? Où l’absence de contexte ralentit-elle une décision ou crée-t-elle un risque ? Où l’IA pourrait-elle être utile, et que devrait-elle savoir sur les personnes, les processus et les données concernés pour le faire de manière responsable ?

Ces questions sont moins enthousiasmantes que de compter les agents, mais elles nous rapprochent beaucoup plus de la valeur.

En ce sens, les agents constituent des preuves concrètes utiles. Ils peuvent montrer ce qui devient possible lorsque l’accès basé sur les rôles, le contexte du cycle de vie et une configuration propre au client sont réunis. Mais ils sont un moyen, pas une destination.

Le marché peut continuer sa course vers les agents. Très bien. Les responsables de l’ingénierie ne doivent simplement pas confondre abondance et progrès.

Les entreprises qui se démarqueront ne seront pas nécessairement celles qui produiront le plus d’agents. Ce seront celles qui rendront l’IA utile au sein de la réalité complexe, gouvernée et hautement spécifique du travail d’ingénierie.

Et c’est pourquoi je reviens sans cesse à l’accès aux données basé sur les rôles. La couche manquante n’est ni le modèle ni l’agent.

La question est de savoir si l’IA peut accéder au contexte dont dépend réellement une décision d’ingénierie, pour la personne qui prend cette décision, sans perdre la gouvernance et la traçabilité qui ont rendu ces informations fiables au départ.