Applications IA : six gestes d’architecture pour éviter le chaos

L’adoption de l’IA a devancé l’organisation des produits qui l’hébergent, multipliant vocabulaires, sorties et comportements d’erreur hétérogènes. Six mouvements d’architecture de l’information et de design proposent une méthode pour reprendre la main, sans reconstruire de zéro.

Refactoriser sur cadence pour éviter l’accumulation invisible

Après le séisme de 1906, les étages endommagés de la maison de San José ont été scellés et la construction a continué ailleurs. Ce réflexe se retrouve dans les équipes qui remplacent une fonctionnalité et laissent l’ancienne active derrière un drapeau sans jamais y revenir. Les trois premiers mouvements proposés ne sont qu’un instantané qui se dégrade avec le temps si rien n’est planifié pour le réconcilier. De nouveaux objets apparaissent sans être nommés dans le contrat initial, des échéances poussent à contourner la bibliothèque de modèles, et des composants sont bifurqués au point d’exister en deux variantes au comportement différent. Ces dérives résultent d’une accumulation normale quand aucun temps n’est réservé à la remise à plat.

Pourquoi tant de surfaces IA finissent disjointes

Près de 90 % des organisations utilisent l’IA, mais la plupart n’ont pas réorganisé leurs flux de travail en conséquence. Les fonctionnalités sont arrivées plus vite que toute structure pour les contenir, avec des vocabulaires, des formats de sortie et des comportements d’erreur divergents. Le sujet relève de l’architecture de l’information, une compétence déjà présente dans les équipes. Le prototypage rend les ajouts peu coûteux, au point de multiplier copilotes, résumés, boutons de rédaction et modèles de données improvisés, chacun opérant de manière isolée. La métaphore de la maison cartographiée pour une visite virtuelle illustre la difficulté à se repérer dans un ensemble sans plan.

Ancrer un modèle d’objet et un contrat sémantique

Avant toute nouvelle capacité, un modèle d’objet partagé doit être défini, avec les noms réels du domaine et les verbes autorisés pour chacun. Des contraintes telles qu’un projet archivable, un document partageable ou une facture approuvable et payable mais non archivable si le métier l’interdit n’existent que si elles sont écrites. Ce modèle joue le rôle d’échafaudage dont dépend le reste. Une demande comme « créer un suivi » doit se poser sur un objet défini avec un domicile persistant, faute de quoi elle invente une entité sans ancrage. Concrètement, il s’agit de lister les noms avant les fonctionnalités, de contrôler chaque action contre un objet réel et de publier un contrat sémantique commun approuvé par l’ingénierie et le design.

Standardiser les comportements via une bibliothèque de modèles

Il est nécessaire qu’une bibliothèque restreinte de modèles d’interaction encadre les comportements dans la durée : suggestion, rédaction, synthèse, classification, planification et confirmation, chacun traversant des états qui vont de la saisie à la récupération ou à l’annulation. De nombreuses équipes disposent de 40 fonctionnalités sans aucun modèle, ce qui aboutit à 40 manières différentes de gérer l’échec, alors que ce dernier ne constitue pas une situation exceptionnelle. Il faut le concevoir une fois au niveau modèle pour qu’il soit hérité partout, en régulant aussi strictement ce qui s’affiche que ce qui se passe. Les équipes savent déjà construire des langages contrôlés. À l’opérationnel : nommer cinq ou six comportements et documenter leurs états, composer le nouveau à partir de la bibliothèque, ajouter délibérément les modèles manquants et unifier durablement les états d’erreur, de vide, de faible confiance et de délai.

Fermer l’ensemble des sorties et privilégier les charges utiles

Définir un ensemble fermé de composants de sortie comme des cartes, des différences, des tableaux, des frises chronologiques ou des préremplissages de formulaires permet de cadrer les surfaces. Toute proposition sur mesure doit justifier pourquoi rien dans l’ensemble ne convient. Les réponses des fonctionnalités doivent revenir sous forme de charges utiles structurées que le frontal rend via des composants existants, avec des schémas dérivés de leurs propriétés, plutôt que sous forme de texte libre.

Maintenir la carte du produit comme un document vivant

Dans beaucoup d’équipes, l’architecture de l’information est restée figée depuis le lancement alors que des dizaines de capacités se sont ajoutées. Sans carte à jour, il est impossible de voir la forme actuelle du produit ni de traiter la dérive ; la carte doit être vivante. Cela implique de la redessiner à chaque livraison en l’intégrant à la définition de terminé, de la générer à partir des routes et de la navigation du code puis de la réconcilier avec la version dessinée, et de nommer un responsable par niveau. L’histoire d’une maison construite en continu, sans plan, rappelle le risque d’empilement. À l’inverse, des demandes autrefois absurdes comme une maison entre deux et quarante-cinq chambres ou un toit en 48 heures sont aujourd’hui techniquement faisables grâce au prototypage, ce qui rend d’autant plus nécessaire d’appliquer ces six mouvements pour canaliser la vitesse.