Pendant plusieurs années, parler d’intelligence artificielle revenait presque mécaniquement à parler des modèles.
Quel modèle possède le plus de paramètres ? Lequel obtient les meilleurs résultats aux benchmarks ? OpenAI est-il devant Anthropic ? Gemini a-t-il rattrapé Claude ? Quel laboratoire vient de publier le nouveau modèle de référence ?
Cette compétition n’est évidemment pas terminée. Les modèles continueront à progresser. Mais pour les entreprises et les architectes, une autre question devient progressivement plus importante :
Et si le modèle n’était désormais plus le problème le plus intéressant ?
Nous sommes peut-être en train de passer de l’ère du modèle d’intelligence artificielle à celle du système d’intelligence artificielle.
Et cette transition change profondément la manière dont l’IA doit être abordée.
La course au meilleur modèle atteint ses limites pratiques
La première phase de l’IA générative a été dominée par une logique relativement simple : améliorer le modèle.
Plus de paramètres. Davantage de données. Des fenêtres de contexte plus grandes. Des infrastructures d’entraînement toujours plus importantes. Des capacités de raisonnement améliorées.
Cette compétition a produit des progrès extraordinaires.
Elle a également installé une manière particulière de penser l’IA : comme si la qualité d’un système dépendait principalement de la puissance du modèle placé en son centre.
Le marché s’est alors mis à vivre au rythme des classements.
OpenAI domine.
Puis Anthropic progresse.
Google semble en retard.
Puis Gemini revient.
Des modèles open source réduisent l’écart.
Des acteurs chinois apparaissent rapidement parmi les modèles les plus compétitifs.
Quelques mois plus tard, une nouvelle génération remet une partie du classement en question.
Le problème n’est pas cette compétition. Elle continuera probablement encore longtemps.
Le problème apparaît lorsque la stratégie d’architecture d’une entreprise commence elle-même à suivre cette compétition.
Car le meilleur modèle du trimestre n’est pas nécessairement le meilleur composant d’un système d’information.
« Suffisamment bon » peut être meilleur que « meilleur »
Cette distinction conduit à une question rarement posée :
de quel niveau d’intelligence avons-nous réellement besoin ?
Imaginons un modèle extrêmement avancé fournissant une qualité que l’on pourrait arbitrairement noter 98/100.
Un modèle beaucoup plus petit atteint 88/100.
Mais le second fonctionne localement, répond rapidement, coûte beaucoup moins cher, ne nécessite pas d’envoyer les données vers une infrastructure extérieure et peut être entièrement contrôlé par l’organisation.
Pour certaines tâches, les dix points supplémentaires ont très peu de valeur économique.
Une classification de documents n’a pas nécessairement besoin du meilleur modèle de raisonnement disponible au monde.
Une extraction d’informations non plus.
Une catégorisation de tickets support encore moins.
Une entreprise peut même utiliser différents niveaux de modèles selon les tâches.
La question devient alors :
Quel est le plus petit niveau d’intelligence permettant d’accomplir correctement cette tâche ?
C’est un changement majeur.
Nous ne cherchons plus systématiquement l’intelligence maximale.
Nous cherchons l’intelligence suffisante dans la bonne architecture.
Le LLM n’est pas le système
Un modèle linguistique peut produire une excellente réponse.
Mais une entreprise n’a généralement pas besoin d’une excellente réponse isolée.
Elle veut accomplir quelque chose.
Créer un ticket.
Analyser une facture.
Interroger une base de données.
Qualifier un prospect.
Lire un dossier.
Produire un document.
Déclencher une procédure.
Comparer des informations.
Envoyer une notification.
Mettre à jour un système.
Dès que l’intelligence artificielle doit agir dans un environnement réel, le modèle ne constitue plus qu’une partie du problème.
Autour de lui apparaissent immédiatement d’autres couches :
Applications métier
↓
Interfaces / API
↓
Orchestration
↓
Routage
↓
Modèles
↓
Tools / données
↓
Automatisation
↓
Contrôles
↓
Actions
Et transversalement :
Identity - Security - Permissions - Logging - Monitoring - Cost Control - Containment
Autrement dit, nous retrouvons de l’informatique.
- Des API.
- Des bases de données.
- Des systèmes d’identité.
- Des droits d’accès.
- Des réseaux.
- Des moteurs de règles.
- Des logs.
- Des environnements d’exécution.
- Des mécanismes de reprise.
- Des systèmes de supervision.
La révolution de l’intelligence artificielle finit ainsi par rencontrer plusieurs décennies d’ingénierie informatique.
Le véritable problème commence lorsque l’IA peut agir
Prenons un assistant conversationnel.
S’il produit une mauvaise réponse, le problème reste relativement contenu.
Donnons maintenant au même système la capacité de consulter une messagerie, d’interroger un CRM, d’accéder au Data Warehouse, d’appeler des API, de modifier des tickets et d’envoyer des emails.
Nous n’avons plus simplement un chatbot.
Nous avons créé un acteur du système d’information.
Et la question la plus importante n’est soudainement plus :
Quel benchmark obtient son LLM ?
Elle devient :
Que sommes-nous prêts à lui permettre de faire ?
- Peut-il seulement lire ?
- Peut-il écrire ?
- Dans quelles tables ?
- Avec quelles permissions ?
- Peut-il envoyer un email sans validation ?
- Peut-il appeler une API externe ?
- Peut-il exécuter du code ?
- Quelles informations peut-il transmettre à un modèle distant ?
- Combien d’actions peut-il effectuer avant qu’une validation humaine soit nécessaire ?
- Comment détecter un comportement anormal ?
- Comment interrompre son exécution ?
- Comment revenir en arrière ?
C’est ici qu’apparaît une notion fondamentale : le containment.
Containment : concevoir le système en supposant que l’IA se trompera
La sécurité informatique s’est construite autour d’un principe simple : ne jamais supposer qu’un composant fonctionnera toujours correctement.
L’IA ne devrait pas bénéficier d’une exception.
Un modèle peut mal comprendre une instruction.
Il peut produire une hallucination.
Il peut interpréter incorrectement une donnée.
Il peut recevoir une instruction malveillante.
Il peut sélectionner le mauvais outil.
Il peut entreprendre une action techniquement valide mais fonctionnellement absurde.
Le problème architectural n’est donc pas seulement d’empêcher l’erreur.
Il faut également limiter le rayon d’impact de cette erreur.
Un agent chargé de consulter des commandes n’a aucune raison de disposer d’un accès administrateur à la base de données.
Un assistant chargé de préparer des emails n’a pas nécessairement besoin du droit de les envoyer.
Un modèle chargé d’analyser des documents internes n’a peut-être aucune raison d’accéder librement à Internet.
On retrouve alors des principes parfaitement connus de l’ingénierie informatique :
- Least privilege.
- Isolation.
- Sandboxing.
- Secrets management.
- Audit logging.
- Human approval.
- Rate limiting.
- Rollback.
Plus nous donnons d’autonomie à l’IA, plus ces mécanismes deviennent importants.
La sophistication du modèle ne supprime donc pas la nécessité d’une architecture robuste.
Elle la rend encore plus nécessaire.
L’orchestration plutôt que le choix d’un champion
Pourquoi une entreprise devrait-elle nécessairement choisir un seul modèle ?
Une architecture mature pourrait utiliser un petit modèle local pour classifier une demande, un autre pour extraire certaines informations, un modèle plus puissant pour les raisonnements complexes et un service spécialisé pour traiter une image, une voix ou une vidéo.
Le système pourrait déterminer automatiquement quel composant utiliser.
Une demande simple serait traitée localement.
Une demande complexe serait envoyée vers un frontier model.
Une donnée sensible ne quitterait jamais l’infrastructure interne.
Une tâche déterministe serait confiée à du code classique plutôt qu’à un LLM.
Une opération critique nécessiterait une validation humaine.
Nous passons alors de :
« Quel LLM avons-nous choisi ? »
à :
« Comment notre architecture choisit-elle la bonne capacité pour la bonne tâche ? »
Le modèle devient progressivement un service interchangeable.
L’orchestration devient la couche qui transforme ces capacités dispersées en système cohérent.
L’automatisation est l’endroit où apparaît la valeur
Un chatbot spectaculaire peut impressionner.
Mais une entreprise ne gagne pas nécessairement de l’argent parce qu’un modèle écrit légèrement mieux qu’un autre.
La valeur apparaît lorsque cette capacité s’insère dans un processus.
Un email est reçu.
Son contenu est compris.
Les informations nécessaires sont extraites.
Le dossier correspondant est identifié.
Les données sont contrôlées.
Une proposition d’action est générée.
Les règles métier sont vérifiées.
Une validation humaine intervient si nécessaire.
Le système métier est mis à jour.
L’utilisateur est informé.
Cette chaîne peut produire une véritable valeur opérationnelle.
Et, paradoxalement, elle ne contient peut-être qu’une ou deux étapes nécessitant réellement un LLM.
Le reste relève de l’intégration, des règles métier et de l’automatisation.
C’est une distinction fondamentale :
L’IA n’est pas nécessairement le processus. Elle devient une capacité intégrée au processus.
La performance du système remplace progressivement la performance du modèle
Cela conduit finalement à revoir ce que nous appelons « performance ».
Dans une approche centrée sur les modèles :
Performance IA = performance du modèle
Dans une approche centrée sur les systèmes :
Performance IA = intelligence suffisante + qualité des données + intégration + fiabilité + sécurité + disponibilité + observabilité + maîtrise des coûts
Un modèle extrêmement performant placé dans une architecture médiocre peut produire un mauvais système.
À l’inverse, un modèle moins performant placé dans une excellente architecture peut produire énormément de valeur.
Cette distinction devient particulièrement importante lorsque l’on commence à industrialiser l’IA.
La dépendance fournisseur devient une question d’architecture
Il existe enfin une autre dimension souvent sous-estimée : la dépendance.
Que se passe-t-il si l’ensemble d’un produit repose sur un fournisseur unique et que son prix change ?
Si ses conditions d’utilisation évoluent ?
Si une fonctionnalité disparaît ?
Si les limites d’utilisation changent ?
Si son service devient indisponible ?
Si une contrainte réglementaire ou géopolitique intervient ?
Nous retrouvons ici une problématique parfaitement connue dans le cloud : le vendor lock-in.
Une architecture conçue autour d’une abstraction des modèles possède alors un avantage considérable.
Aujourd’hui, une tâche peut être confiée à Claude.
Demain à Gemini.
Une autre à OpenAI.
Les données sensibles à un modèle local.
Une opération déterministe à du code traditionnel.
Le choix du modèle devient une décision d’exécution plutôt qu’un choix structurant pour l’ensemble du système.
Une architecture ne devrait pas dépendre du classement du trimestre
L’évolution récente du marché devrait justement nous rendre prudents.
Il y a quelques années, certains considéraient déjà la compétition comme terminée.
OpenAI semblait disposer d’une avance considérable.
Google était parfois présenté comme ayant raté le virage de l’IA générative.
Puis Gemini a progressé.
Anthropic s’est imposé parmi les acteurs majeurs.
Les modèles open source se sont améliorés.
Les modèles chinois ont gagné en crédibilité.
Les coûts d’inférence ont diminué.
Les petits modèles sont devenus étonnamment capables.
Et le classement continue d’évoluer.
Il existe une conclusion architecturale très simple à cette instabilité :
Une architecture destinée à vivre dix ans ne devrait pas dépendre du classement des LLM d’un trimestre donné.
Elle doit pouvoir absorber leur évolution.
De « model-centric » à « system-centric »
C’est peut-être finalement le changement de paradigme le plus important.
La première phase de l’IA générative était largement :
Model-centric.
La prochaine sera probablement beaucoup plus :
System-centric.
Dans une approche model-centric, la question principale est :
Quel est le meilleur modèle ?
Dans une approche system-centric, les questions deviennent :
Quel modèle est suffisamment bon pour cette tâche ?
Où doit-il s’exécuter ?
À quelles données peut-il accéder ?
Quels outils peut-il appeler ?
Quelle identité utilise-t-il ?
Quelles actions peut-il effectuer ?
Comment orchestrer plusieurs modèles ?
Comment contrôler son coût ?
Comment observer son comportement ?
Comment contenir ses erreurs ?
Quand faut-il demander une validation humaine ?
Comment remplacer demain le modèle utilisé aujourd’hui ?
Voilà où commence véritablement le travail d’architecture.
L’intelligence devient un composant
Pendant les premières années de l’IA générative, l’intelligence semblait constituer le produit.
Elle pourrait progressivement devenir une infrastructure.
Un composant accessible par API.
Un modèle local.
Un service spécialisé.
Une capacité que l’on appelle lorsque le processus en a besoin.
À mesure que cette intelligence devient disponible, la différenciation se déplace ailleurs.
- Vers les données.
- Vers les processus métier.
- Vers l’intégration.
- Vers l’expérience utilisateur.
- Vers la sécurité.
- Vers l’automatisation.
- Vers l’orchestration.
- Vers la connaissance métier.
Autrement dit, vers le système construit autour du modèle.
Les frontier models continueront à progresser. OpenAI, Anthropic, Google et leurs concurrents continueront à annoncer de nouvelles générations. Les benchmarks continueront à produire des gagnants et des perdants.
Mais pour celui qui construit réellement des systèmes, une question devient progressivement plus importante :
Que pouvons-nous construire avec une intelligence déjà suffisamment bonne ?
Car après la course aux modèles commence probablement une phase moins spectaculaire, mais beaucoup plus déterminante pour les entreprises :
le temps de l’architecture.