Pourquoi 5BY.AI reste stable même quand les services IA changent : la conception du Provider Adapter

ChatGPT, Claude, Gemini, Copilot, Perplexity, DeepSeek, Mistral et Grok ont des écrans et des structures de conversation différents.

Un même service IA peut, au fil des mises à jour, modifier sa façon d'afficher les messages, la structure de sa zone de saisie, et les informations qui distinguent les conversations.

Si 5BY.AI, qui relie les conversations de plusieurs IA, était directement ébranlé par ces changements, chaque petite modification d'écran d'un service spécifique pourrait affecter la sauvegarde, la connexion, la recherche et le graphe.

C'est pourquoi 5BY.AI isole les changements de chaque Provider IA par rapport aux fonctionnalités centrales.

Le principe de base est que les parties propres à chaque Provider sont absorbées par l'Adapter, et le Core traite les pensées et le contexte de l'utilisateur de manière cohérente.

Les changements des Providers IA sont inévitables

Les services IA évoluent rapidement.

De nouveaux modèles et fonctionnalités sont ajoutés, l'écran de conversation et la position des boutons changent, et la structure interne d'affichage des messages se modifie.

Ce qui semble être un petit changement d'écran pour l'utilisateur peut être une modification importante pour les outils qui reconnaissent les conversations dans le navigateur.

Par exemple, les éléments suivants peuvent changer :

• La façon de distinguer les messages utilisateur des réponses de l'IA
• La structure de l'écran affichant la conversation
• Le processus d'ajout ou de modification des messages
• La position de la zone de saisie et du bouton d'envoi
• L'adresse et l'identifiant de la conversation
• La façon d'afficher les réponses régénérées

Ces changements surviennent naturellement au fil de l'amélioration de chaque service Provider.

Le problème n'est pas le changement en soi.

C'est l'étendue de l'impact d'un changement d'un Provider sur l'ensemble de la structure de 5BY.AI.

L'Adapter prend en charge les parties propres à chaque Provider

L'Adapter est la frontière qui comprend l'écran et la structure de conversation de chaque service IA.

La façon de lire l'écran de ChatGPT et celle de lire l'écran de Copilot peuvent différer. La structure des messages de Claude et celle de Mistral ne peuvent pas non plus être supposées identiques.

L'Adapter traite ces différences au sein de chaque Provider.

Ses rôles principaux sont les suivants :

• Identifier le Provider IA actuel.
• Détecter les messages utilisateur et les réponses de l'IA.
• Interpréter la structure d'écran propre à chaque Provider.
• Organiser les informations de conversation nécessaires dans un format commun.
• Transmettre le résultat organisé à la couche suivante.

L'important est que l'Adapter n'est pas le lieu où l'on évalue les pensées de l'utilisateur ou où l'on détermine les conversations importantes.

L'Adapter se concentre sur le rôle de détecter et de traduire les différences entre Providers.

Le Core peut connaître le Provider mais ne doit pas en dépendre

Ce que le Core de 5BY.AI doit savoir se limite à « de quel Provider provient ce message ».

Mais il ne doit pas connaître la structure d'écran, les sélecteurs ou la position des boutons d'un Provider spécifique.

Par exemple, si les jugements suivants s'accumulent dans le Core, des problèmes surviennent :

• Pour ChatGPT, on traite de cette façon.
• Pour Claude, on cherche d'autres éléments d'écran.
• Pour Gemini, on ne sauvegarde que si un bouton spécifique est présent.
• Pour Copilot, on utilise une structure de messages distincte.

Si ces conditions propres à chaque Provider s'accumulent dans le Core, il faut modifier la structure centrale à chaque ajout d'une nouvelle IA ou à chaque mise à jour d'un service existant.

Un petit changement d'écran peut alors affecter l'unité de sauvegarde, la connexion de contexte et la Graph View.

C'est pourquoi 5BY.AI sépare les différences propres à chaque Provider pour qu'elles ne pénètrent pas le Core.

Le Core traite le flux de pensée de l'utilisateur à partir des informations en format commun transmises par l'Adapter.

Un changement d'un Provider ne doit pas affecter les autres Providers

<arg_value>L'objectif le plus important de la séparation de l'Adapter est de limiter la portée des modifications.

Par exemple, imaginons que l'écran de conversation de Perplexity ait changé.

Dans une structure correctement séparée, les modifications doivent se concentrer sur l'Adapter Perplexity.

Ce changement ne doit pas entraîner la modification des fonctionnalités suivantes :

• Détection des conversations ChatGPT
• Sauvegarde des messages Claude
• Anchor créé dans Gemini
• Handoff poursuivi depuis DeepSeek
• Saved de la conversation Mistral
• Graph View des enregistrements Copilot
• Connexion des pensées générées dans Grok

Même si un Provider change, les autres Providers et les fonctionnalités communes de 5BY.AI doivent rester intacts.

C'est ce que signifie « l'Adapter absorbe l'impact des changements ».

Sans Adapter, le Core est facilement contaminé

Lorsqu'on ne prend en charge qu'une ou deux IA au début, insérer directement les conditions propres à chaque Provider dans le code central peut sembler plus rapide.

Mais à mesure que le nombre de Providers augmente, le même problème se répète.

Des exceptions propres à chaque Provider s'ajoutent, et pour modifier une fonctionnalité, il faut vérifier les conditions de plusieurs services simultanément.

Avec le temps, le Core peut devenir non plus la zone qui traite le flux de pensée de l'utilisateur, mais un dépôt d'exceptions propres à chaque Provider.

Dans cet état, les problèmes suivants surviennent :

• Il est difficile de prévoir la portée d'un petit changement.
• En modifiant un Provider, on risque de casser un autre Provider.
• La complexité augmente rapidement à chaque ajout de Provider.
• La frontière entre les fonctionnalités communes et le code spécifique à un Provider devient floue.
• Il devient difficile de distinguer si la cause d'une panne est un changement d'écran ou un problème de Core.

La séparation de l'Adapter n'est pas simplement une façon d'organiser le code.

C'est une structure qui protège les fonctionnalités centrales de 5BY.AI contre la contamination par les changements fréquents des Providers.

Anchor et Handoff ne doivent pas dépendre de l'écran d'un Provider

Les fonctionnalités importantes de 5BY.AI ne sont pas conçues pour l'écran d'un service IA spécifique.

L'Anchor conserve le point de référence d'une pensée digne d'être reprise.

Le Saved sélectionne les conversations importantes à réexaminer plus tard.

Le Handoff relie le contexte des objectifs et des jugements formés jusqu'à présent à une nouvelle conversation IA.

La Graph View permet d'explorer les relations entre différentes conversations et pensées.

Le sens de ces fonctionnalités ne doit pas changer selon qu'on les utilise dans ChatGPT, DeepSeek ou Grok.

Chaque Provider peut afficher les messages différemment.

Mais les pensées que l'utilisateur a jugées importantes et le contexte à poursuivre doivent être traités dans une structure commune.

L'Adapter traite les différences d'écran, et le Core, au-delà de ces différences, gère le flux de pensée de l'utilisateur de manière cohérente.

Le même principe s'applique lors de l'ajout d'une nouvelle IA

Dans un service multi-LLM, la prise en charge d'un nouveau Provider n'est pas simplement l'ajout d'une adresse de site.

Il faut comprendre comment chaque service affiche les conversations, comment les messages sont générés, et comment l'utilisateur poursuit la conversation.

Mais si l'ajout d'un nouveau Provider exige de modifier le Core existant, les coûts et les risques d'extension ne cessent de croître.

Dans une bonne structure de séparation, le nouveau Provider suit le processus suivant :

1. L'Adapter comprend l'écran et la structure de conversation du nouveau Provider.
2. Les informations détectées sont organisées dans le format commun de 5BY.AI.
3. Le Core et la structure de stockage existants traitent les données de la même façon.
4. Anchor, Saved, Handoff et la Graph View conservent leur sens existant.

Même lors de la prise en charge d'une nouvelle IA, l'utilisateur ne doit pas avoir besoin d'apprendre une façon complètement différente d'utiliser 5BY.AI.

Le nombre de Providers peut augmenter, mais le comportement central de 5BY.AI doit rester cohérent.

Pour l'utilisateur, ce qui compte est la stabilité, pas la structure interne

L'utilisateur n'a pas besoin de comprendre la différence entre l'Adapter et le Core.

Ce que l'utilisateur attend est plus simple :

• Même si le service IA est mis à jour, on peut continuer à conserver les conversations importantes.
• Un problème d'un Provider spécifique ne doit pas dégrader l'expérience avec d'autres IA.
• Quel que soit l'IA utilisé, le sens de l'Anchor et du Handoff doit être le même.
• Même si une nouvelle IA est ajoutée, les enregistrements et les connexions de pensée existants doivent être maintenus.
• Même en passant d'une IA à l'autre, la façon d'utiliser 5BY.AI doit rester cohérente.

La séparation de l'Adapter est une conception interne destinée à protéger cette expérience utilisateur.

C'est une structure invisible, mais elle détermine la capacité du service à répondre aux changements de manière stable.

Les Providers changent, mais le flux de pensée de l'utilisateur doit se poursuivre

Les Providers IA changent en permanence.

Les écrans évoluent, des fonctionnalités sont ajoutées, et la structure des conversations et le mode d'utilisation peuvent se modifier.

Il est nécessaire que 5BY.AI s'adapte continuellement à ces changements.

Mais ce qui n'a pas besoin de changer ne doit pas être ébranlé avec eux.

L'écran et la méthode de détection propres à chaque Provider peuvent changer dans l'Adapter.

En revanche, l'expérience centrale — sélectionner les pensées importantes de l'utilisateur, conserver le contexte, poursuivre dans une autre IA, et réexaminer les relations — doit rester stable.

Les changements des Providers sont absorbés par l'Adapter, et le Core protège le flux de pensée de l'utilisateur.

Ce principe est la conception fondamentale qui permet à 5BY.AI de prendre en charge plusieurs IA sans être dépendant d'un Provider spécifique.

Les services IA continueront de changer.

Mais il n'est pas nécessaire que les pensées importantes laissées par l'utilisateur et les coordonnées pour poursuivre soient ébranlées avec eux.

Articles et fonctionnalités associés

• Comment maintenir le contexte des conversations IA entre plusieurs LLM
• UI/UX des services IA : comment 5BY.AI transforme des fonctionnalités complexes en actions simples
• Pourquoi 5BY.AI laisse l'utilisateur choisir lui-même les conversations importantes
• Comment reprendre au point où la pensée s'est arrêtée après une interruption de conversation IA
• Découvrir les fonctionnalités de 5BY.AI Tools
• Voir l'installation et l'utilisation de 5BY.AI