Pour les entreprises qui utilisent l'IA aujourd'hui, une seule chose compte : ce que vous construisez maintenant fonctionnera-t-il encore et sera-t-il encore rentable quand le marché basculera ? Ce basculement peut aller dans deux directions. Les prix peuvent augmenter quand la subvention s'arrête, mais ils peuvent aussi continuer à baisser, et vous payez alors trop si vous êtes lié à un seul fournisseur. D'un autre côté, des modèles peuvent disparaître rapidement. Opus 5 a été remplacé après deux mois à peine. Construire votre application autour d'un seul modèle spécifique, c'est bâtir sur du sable.
Une architecture qui absorbe ces chocs présente quelques caractéristiques fixes :
Premièrement, une couche d'abstraction se trouve entre vos applications et les modèles. Il peut s'agir d'une passerelle IA qui reçoit chaque appel et le transmet au modèle que vous avez choisi. Dans l'écosystème Microsoft, c'est possible par exemple avec les fonctions de passerelle IA d'Azure API Management, tandis qu'Azure AI Foundry rassemble des modèles de différents fournisseurs. Changer de modèle devient alors un choix de configuration, sans devoir tout reconstruire. Utilisez les fonctions propres à un fournisseur en connaissance de cause. Documentez-les, afin de savoir ce que vous devrez remplacer le moment venu.
Deuxièmement, vous routez par tâche. Un modèle haut de gamme n'est nécessaire que pour une partie de vos requêtes. Une classification ou un résumé fonctionne très bien sur un modèle vingt fois moins cher. Vous réservez le modèle haut de gamme au travail qui fait la différence. C'est souvent là que se trouvent les plus grandes économies, plus importantes que n'importe quelle baisse de prix.
Troisièmement, vous disposez de votre propre jeu d'évaluation. Un ensemble de tâches représentatives avec les résultats attendus vous permet de décider en une journée si un modèle nouveau ou moins cher est suffisant. Sans un tel jeu, chaque changement de modèle reste un pari, et vous ne changez donc pas.
Quatrièmement, votre savoir reste le vôtre : vos prompts, votre contexte, votre documentation et vos données. Ils doivent être indépendants du modèle, afin de pouvoir passer au suivant.
Cinquièmement, vous gardez un voyant d'alerte sur vos coûts courants. Mesurez vos coûts par application, par client et par tâche accomplie, et pas seulement par token. Fixez des budgets et des seuils, pour repérer un processus qui s'emballe ou un agent pris dans une boucle au bout d'une heure, et pas seulement sur la facture mensuelle. Ce que vous ne mesurez pas, vous ne pouvez pas le piloter, et avec une tarification à la consommation, la facture grimpe sans que vous vous en rendiez compte.
Enfin, vous avez une solution de repli. Un modèle open-weight que vous hébergez vous-même ou confiez à un partenaire européen couvre une partie de vos applications et sert d'assurance contre un choc de prix ou un fournisseur qui modifie ses conditions. Il est aussi utile pour les données qui ne peuvent pas quitter l'Europe.
Au fond, tout cela est un terrain connu. C'est la même discipline que celle que nous avons apprise avec le cloud il y a vingt ans : ne pas devenir dépendant d'un seul acteur, mesurer ce que l'on consomme et veiller à pouvoir partir. Avec l'IA, tout va simplement plus vite et les prix bougent un peu plus fort.
:focal())
