MTS: les premières décisions architecturales en AI prises aujourd’hui fixent des limites pour les décennies à venir

Un texte de MTS sur Habr AI propose de voir le développement de l'intelligence artificielle non pas comme une course de modèles, mais comme une accumulation de décisions architecturales qui vivent des décennies. L'idée principale est simple : les premières couches de code, de données et de processus aujourd'hui peuvent devenir une base tout aussi impénétrable pour les futurs systèmes d'IA que le Centre Technologique l'est devenu dans "Hypérion".

Métaphore d'"Hypérion"

L'auteur s'appuie sur le roman "Hypérion" de Dan Simmons, où les intelligences artificielles ont passé des siècles à construire leurs propres systèmes sur du code écrit par les humains. Au fil du temps, l'architecture est devenue si complexe que ni les humains ni les IAs elles-mêmes ne comprenaient pourquoi les mécanismes clés étaient disposés de cette façon. Pour la science-fiction de la fin des années 1980, c'était une image frappante.

Pour l'industrie de l'IA d'aujourd'hui, c'est une description presque littérale de la façon dont la dette technique s'accumule dans les grandes plateformes d'IA. Il est important de noter que cette métaphore ne parle pas de rébellions lointaines de machines, mais d'un vrai problème d'ingénierie. Plus il y a de générations d'équipes, de services et de modèles qui s'empilent les uns sur les autres sans un dessein commun, plus le risque d'aboutir à un système qu'on ne peut pas développer en confiance est élevé.

Il continue de fonctionner, mais les raisons de son comportement deviennent de moins en moins claires. Et là où l'explicabilité de l'architecture disparaît, le coût des changements comme la probabilité d'erreurs augmentent rapidement.

Comment la Complexité Grandit

Le problème ne concerne pas seulement les modèles. Tout produit d'IA est construit par couches : pipelines de données, filtres, bases de données vectorielles, orchestrateurs, prompts système, règles de sécurité, interfaces pour humains, intégrations avec des services externes. Chaque couche émerge généralement en réponse à une tâche métier urgente : accélérer la livraison, réduire les coûts des requêtes, améliorer la qualité des réponses ou atténuer les risques.

Individuellement, ces solutions semblent raisonnables, mais après quelques années elles s'assemblent en une structure difficile à expliquer, à tester et à modifier en toute sécurité. De ce fait, les erreurs architecturales du stade initial s'avèrent particulièrement coûteuses. Si une équipe n'a pas initialement décrit les dépendances, documenté les invariants et convenu où s'arrête la responsabilité du modèle et où commence celle du produit, alors tout cela devient une confusion systémique.

Un modèle peut être réentraîné ou remplacé, mais un contour croissant chaotiquement autour de lui—logging, routage, règles d'escalade, rustines manuelles—survit plus longtemps que le réseau neuronal lui-même et cause plus de problèmes.

Ce Que les Équipes Doivent Faire

C'est pourquoi la conversation sur l'avenir de l'IA se déplace de plus en plus des tailles de modèles vers la qualité des fondations d'ingénierie. Il ne s'agit pas de geler les expériences et de concevoir sans fin un système parfait. Il s'agit d'une discipline minimale, sans laquelle la pile d'IA devient rapidement opaque même pour sa propre équipe. Dans la colonne de MTS, cela ressemble à un avertissement : aujourd'hui le marché est focalisé sur la vitesse, mais le vrai avantage demain ira à ceux qui conçoivent déjà une architecture claire et vérifiable.

• Bien séparer ce que fait le modèle de ce que fait la logique métier du produit
• Documenter les raisons des décisions architecturales clés, pas seulement le code résultant
• Limiter les dépendances cachées entre les données, les prompts, le retrieveur et l'interface
• Construire l'observabilité : logs, traçage, versions de prompts et contrôle de qualité
• Régulièrement supprimer les rustines temporaires avant qu'elles ne deviennent une infrastructure permanente

Cela concerne non seulement les ingénieurs. Les équipes produit, les managers et les leaders influencent aussi la complexité future quand ils exigent d'ajouter encore un flag, de contourner temporairement une limitation ou de rapidement coller deux contours ensemble. Dans les systèmes d'IA, de tels compromis sont particulièrement insidieux : ils se cachent non seulement dans le code, mais dans les données, les paramètres de modèles, les instructions cachées et les opérations manuelles de support. Extérieurement, le produit peut fonctionner, mais intérieurement il est déjà en train de perdre sa capacité à être géré.

Ce Que Cela Signifie

Pour les équipes qui construisent des services d'IA aujourd'hui, la conclusion principale n'est pas que la complexité doit être arrêtée—c'est impossible. La conclusion est différente : chaque solution rapide laisse une marque dans la fondation. Et si ces couches ne sont pas gérées dès le départ, dans quelques années ce seront elles, non la qualité du modèle, qui détermineront le plafond de vitesse, de fiabilité et de sécurité du produit.