Interfaces personnalisables par l’IA : qui maintient les extensions ?

Interfaces personnalisables par l’IA : qui maintient les extensions ?

Un logiciel peut laisser l’utilisateur changer ses couleurs, ses colonnes ou ses raccourcis. Avec l’IA, la demande devient plus ambitieuse : « ajoute le panneau qui me manque, ici, pendant que je travaille ». Le cas de bb, « The IDE that builds itself », rend cette idée tangible. Mais une entreprise qui l’adopte doit répondre à une question moins spectaculaire : qui corrigera ce panneau après la prochaine mise à jour ?

Une interface personnalisable par l’IA doit adapter le poste de travail sans fragmenter le système métier. L’utilisateur peut choisir comment voir et préparer son travail ; les droits d’accès, les règles de calcul et les validations restent communs. Toute nouvelle capacité doit avoir un responsable, des tests et un retour arrière avant de devenir un outil partagé.

Partir de bb : modifier son outil depuis son outil

bb se présente comme un environnement de développement capable de se contrôler, de se personnaliser et de s’automatiser. Un IDE est l’espace dans lequel un développeur travaille sur son code. L’intérêt de cet exemple n’est donc pas de générer un autre logiciel à côté : c’est de faire évoluer l’environnement déjà utilisé.

La demande à examiner est précise : saisir une commande à l’intérieur de l’application pour obtenir une nouvelle interface ou une capacité, sans reconstruire toute l’application. Cette liberté reste contenue dans un environnement et dans les primitives disponibles — les éléments et opérations que le logiciel permet d’assembler. Ce souhait d’un utilisateur avancé ne démontre pas que tous les utilisateurs veulent devenir concepteurs de leur outil.

Le site officiel de bb donne un exemple concret : demander à retrouver ses tickets Linear dans bb. La présentation montre la création d’un plugin, l’ajout d’un panneau latéral, d’une commande bb linear et d’un « skill » qui explique aux agents comment l’utiliser. Elle précise que plusieurs fonctions du produit reposent elles-mêmes sur des plugins. Le dépôt officiel documente aussi un produit encore en développement actif.

Ce que cet exemple établit : l’éditeur décrit une extension de l’espace de travail par plugin, pas seulement une préférence visuelle. Nous n’avons pas installé bb ni exécuté cette intégration de bout en bout ; cette présentation ne mesure ni sa fiabilité en entreprise, ni le temps qu’elle ferait gagner. Elle fournit en revanche un bon point de départ pour poser le contrat de maintenance.

Transposer à l’entreprise sans inventer un résultat client

Scénario illustratif, et non cas client observé : une responsable support traite des demandes dans un outil métier. Comme dans l’exemple Linear de bb, elle voudrait faire venir une information utile dans son espace de travail : « ajoute un panneau avec mes demandes en attente, leur échéance et le prochain engagement à tenir ».

Si les données et les filtres existent déjà, le changement peut rester une composition d’écran. Si le panneau exige de connecter un nouvel outil, de conserver un identifiant d’accès ou de créer une action de relance, il introduit une dépendance supplémentaire. Le même prompt apparent recouvre alors deux travaux différents : afficher autrement des données autorisées, ou ajouter une capacité au système.

Le panneau ne doit pas décider seul de ce qu’est un retard. Cette définition vient du contrat et des règles du support. Il ne doit pas non plus afficher les dossiers d’une autre équipe parce que l’IA a produit une requête trop large. L’application doit vérifier les autorisations côté serveur, même si un bouton ou un filtre est masqué à l’écran.

La personnalisation rend service quand elle évite à cette responsable de jongler entre plusieurs vues. Elle devient coûteuse si chaque collègue obtient sa propre définition d’« urgent », sa copie des règles de relance et un connecteur sans propriétaire. Il faut donc classer les demandes avant de laisser l’IA les produire.

Une grille : seul, avec validation, commun à tous

Cette grille est une proposition de conception pour un outil d’entreprise, pas une liste de garanties fournies par bb.

• Personnalisable seul : ordre des panneaux, densité d’affichage, colonnes, raccourcis et filtres sur les données déjà accessibles. Prévoir une remise à zéro et une vue standard ; empêcher qu’un réglage masque une alerte obligatoire.
• Soumis à validation : nouveau panneau calculé, formule d’indicateur, connecteur, extension générée, export ou action de relance. Un responsable métier valide le sens ; un responsable technique vérifie accès, dépendances et fonctionnement. Une nouvelle formule peut rester personnelle sans devenir une définition officielle.
• Commun à tous : droits, périmètre des données, définition des indicateurs officiels, règles de validation, journal des actions et exigences d’accessibilité. Un changement de ces règles passe par le processus produit et métier, pas par le prompt d’un utilisateur.

Le classement dépend de l’effet réel, pas du vocabulaire de la demande. « Change ce bouton » peut être une préférence d’affichage ; remplacer une confirmation de paiement par une exécution immédiate modifie une règle métier. Si une personnalisation change qui peut agir, sur quoi ou avec quelles conséquences, elle sort de la catégorie libre.

A2UI : composer un catalogue n’est pas charger un plugin

A2UI illustre une autre approche. Le protocole permet à un agent de décrire une interface de façon déclarative : il envoie une description de composants que le client affiche avec ses propres éléments d’interface, au lieu d’exécuter du code arbitraire produit pour cette interface. L’agent compose à partir d’un catalogue de composants préapprouvés.

Cette distinction compte pour la maintenance. Une équipe peut limiter les combinaisons à des cartes, listes et formulaires qu’elle sait déjà tester et rendre accessibles. Avec une extension par plugin, elle doit aussi examiner le code de l’extension, ses dépendances et les capacités qu’elle reçoit. A2UI et les plugins de bb ne sont pas le même mécanisme ; la présence d’un catalogue ne prouve pas non plus que bb utilise A2UI.

Un catalogue réduit la liberté de génération ; il ne garantit pas la sécurité du système. Un composant approuvé peut afficher des données mal autorisées ou déclencher une action mal contrôlée. Le serveur doit toujours appliquer les droits et les règles métier. La qualité des composants, les liaisons aux données et les actions permises restent à tester.

Qui reprend la main quand l’interface casse ?

Le vrai coût apparaît souvent après la création : une API change, un champ disparaît, un plugin n’est plus compatible ou son auteur quitte l’entreprise. L’équipe doit pouvoir identifier les utilisateurs concernés et désactiver l’extension sans bloquer le traitement des demandes.

Avant de diffuser une capacité générée, constituez une fiche courte :

• Un propriétaire : qui répond à l’incident, qui valide les évolutions métier et qui maintient le code ou le catalogue ? L’utilisateur qui a écrit le prompt n’est pas automatiquement le mainteneur.
• Une version identifiable : composants ou plugin, sources de données, dépendances, permissions demandées et version du socle compatible. Conserver le prompt aide à comprendre l’intention, mais ne remplace pas l’artefact livré.
• Des tests utiles : calculs, données absentes, accès refusé, lenteur, erreur et action répétée. Tester l’écran au clavier, avec un lecteur d’écran lorsque pertinent et sur les tailles réellement utilisées.
• Une règle de mise à jour : vérifier les extensions lors des changements du socle ; retirer celles qui n’ont plus de propriétaire au lieu de les laisser devenir invisiblement critiques.
• Un retour arrière : rétablir la vue standard et la version précédente. Si une extension a écrit dans le système, restaurer l’écran ne suffit pas : il faut traiter les écritures effectuées et leurs éventuelles compensations.

Pour notre panneau support, la recette vérifie notamment qu’un agent ne voit pas les demandes d’une équipe non autorisée, qu’une échéance manquante n’est pas présentée comme un engagement tenu et qu’une indisponibilité du connecteur laisse accessible le parcours standard. Ces critères donnent un contenu vérifiable au mot « prêt ».

Tester la valeur avant de généraliser la liberté

Commencez par un poste de travail et une tâche. Relevez le temps complet, les reprises, les erreurs et le support nécessaire avec la vue actuelle, puis avec la vue personnalisée. Ajoutez le temps de contrôle, de correction et de maintenance ; des minutes gagnées à l’écran peuvent être absorbées ailleurs. Notre guide pour choisir un premier projet IA en PME détaille cette lecture du coût complet.

Testez aussi avec une personne qui n’a pas formulé le prompt. Comprend-elle le panneau sans son créateur ? Sait-elle retrouver la vue standard et signaler une donnée douteuse ? Le test utilisateur d’un prototype IA sert précisément à observer une tâche sans confondre démonstration accompagnée et usage autonome.

Si plusieurs personnes demandent le même panneau, il mérite peut-être d’entrer dans le produit commun. S’il ne sert qu’à une personne mais exige un connecteur fragile, mieux vaut parfois garder une personnalisation plus simple. L’objectif n’est pas de multiplier les versions : c’est de rapprocher l’outil du travail sans disperser les responsabilités.

Cadrer une interface personnalisable avec SAY Digital

Vous envisagez de laisser vos utilisateurs adapter un outil métier ? SAY Digital peut vous aider à délimiter les libertés utiles, les règles communes et un pilote testable. Un cadrage doit préciser le parcours, les données accessibles, le responsable de chaque extension et les conditions de retour à la version standard avant de lancer le développement.

Échangeons sur votre outil et sur ce qui doit rester commun.

Sources

• bb — présentation officielle : personnalisation par plugins et exemple d’intégration Linear. Présentation de l’éditeur, pas benchmark indépendant.
• bb — dépôt officiel et README : environnement agentique, surfaces d’accès et état de développement.
• A2UI — documentation officielle : description déclarative et catalogue de composants préapprouvés, mécanisme distinct des plugins.

Sources consultées le 28 octobre 2026. Analyse documentaire ; scénario support et grille de décision proposés à titre illustratif. Aucun déploiement ni gain de productivité mesuré n’est revendiqué.