IA ouverte : le vrai coût d’une tâche réussie

Modèles ouverts, hébergement et contrôle humain : comment comparer les solutions à partir du travail réellement accompli.

Une réponse automatique qu’il faut entièrement réécrire coûte du temps, même lorsque son calcul ne coûte presque rien. L’IA ouverte rend ce décalage particulièrement visible : accéder à un modèle bon marché ne suffit pas à rendre un service rentable. Pour une jeune entreprise comme pour une PME, le bon indicateur est le coût d’une tâche terminée avec le niveau de qualité promis au client.

Cette façon de compter change les décisions : quel travail automatiser, où faire fonctionner le modèle, quand solliciter une personne ? Elle permet aussi de tester les modèles ouverts sans parier toute son activité sur leurs performances.

Des calculs moins chers peuvent gonfler la facture

Y Combinator fait état d’une consommation de jetons multipliée par 150 sur Ollama Cloud depuis le début de 2026, dans la présentation de son entretien avec Jeffrey Morgan, cofondateur et dirigeant d’Ollama. Le passage consacré à l’essor des volumes traités commence à 03:31. Ce chiffre décrit l’activité d’une plateforme ; il ne mesure ni les économies de ses clients ni la productivité des entreprises.

Les jetons sont les fragments de texte qu’un modèle traite ou produit. Leur prix intéresse les développeurs, mais une demande client peut nécessiter plusieurs appels au modèle, des recherches et des vérifications. Si chaque appel devient moins coûteux, l’entreprise peut multiplier les usages et voir sa dépense totale augmenter.

Le calcul utile consiste donc à additionner les dépenses de calcul, d’exploitation et de contrôle humain, puis à les rapporter aux tâches effectivement réussies. Les tentatives abandonnées et les corrections restent dans les dépenses. Une économie sur le calcul ne devient une économie pour l’entreprise que si le travail est réellement terminé.

Confier aux modèles un travail bien délimité

Par modèles ouverts, on désigne ici des modèles dont les paramètres appris, souvent appelés « poids », sont accessibles pour les faire fonctionner dans un environnement choisi. Cela ne signifie pas que tous leurs composants sont publics ni que tous les usages sont autorisés. L’IA ouverte exige donc de vérifier les conditions d’utilisation du modèle retenu.

Prenons un cas hypothétique : une petite entreprise de logiciels veut préparer les réponses de son service client francophone. Repérer le produit concerné et retrouver une procédure ne demandent pas le même jugement que répondre à une réclamation ambiguë. Tester séparément ces tâches permet de déterminer où un modèle économique suffit et où une intervention supplémentaire apporte de la valeur.

Le débat entre modèle unique et orchestration, à 31:35, fournit une piste : répartir le travail entre plusieurs composants. Pour l’entreprise, cette organisation doit rester simple à contrôler. Un modèle peut préparer une réponse courante ; un cas mal documenté doit pouvoir revenir à une personne, sans inventer une explication pour terminer coûte que coûte.

Cette répartition se juge sur des demandes réelles, avec leurs fautes, leurs formulations elliptiques et leur vocabulaire professionnel. Construire des agents d’IA fiables en entreprise suppose notamment de définir les actions autorisées et les situations où le système doit s’arrêter. Un français fluide ne prouve pas qu’une réponse est juste.

Choisir l’hébergement en comptant le temps de l’équipe

Le caractère ouvert du modèle et son lieu d’exécution sont deux choix distincts. La documentation d’Ollama décrit une exécution sur ses serveurs distants, tandis que sa foire aux questions précise les possibilités d’utilisation locale. Un modèle ouvert ne fonctionne donc pas nécessairement sur l’ordinateur de l’entreprise.

L’hébergement chez un prestataire peut faciliter un essai sans achat de matériel. Faire fonctionner le modèle sur ses propres machines peut offrir davantage de maîtrise, mais mobilise des compétences : installation, mises à jour, surveillance et résolution des pannes. Pour une équipe réduite, les heures consacrées à cette exploitation doivent figurer dans le comparatif.

Avant de s’équiper, mieux vaut évaluer les solutions de calcul adaptées à ses usages. Une machine sous-utilisée reste une dépense ; une machine saturée peut rallonger les délais. Le volume moyen ne suffit donc pas : testez aussi les moments où plusieurs clients sollicitent le service simultanément.

La même précision s’impose pour les données : où passent les documents, qui peut y accéder, quelles traces l’application conserve-t-elle ? Le nom du modèle ne répond à aucune de ces questions. Dessiner le parcours d’une demande, du message reçu à la réponse envoyée, aide à repérer les dépendances techniques et les responsabilités.

L’expertise métier permet de reconnaître une réussite

Dans notre exemple de service client, une réponse réussie doit respecter la procédure applicable, répondre à la demande et éviter une nouvelle prise de contact inutile. Ces critères viennent des personnes qui connaissent les clients. Ils rendent la comparaison entre modèles beaucoup plus utile qu’une démonstration choisie pour impressionner.

Un entrepreneur peut ainsi s’appuyer sur son expérience métier pour créer une entreprise avec l’IA : identifier les cas difficiles, expliciter les règles et constituer des exemples de travail bien fait. Savoir reconnaître une tâche réussie devient une compétence centrale pour choisir son IA.

Gardez aussi quelques demandes inédites pour vérifier que la solution fonctionne au-delà des exemples utilisés pendant sa mise au point. À chaque changement de modèle, reprenez les mêmes critères. Une amélioration de vitesse ne justifie pas automatiquement une baisse de qualité.

À retenir : commencer par une tâche mesurable

Le premier essai peut rester modeste : une tâche fréquente, un résultat attendu et une personne capable de l’évaluer. Comparez ensuite les options avec la même méthode :

• Définissez ce qui compte comme une réussite avant de lancer les essais.
• Mesurez les délais, les corrections et toutes les dépenses nécessaires.
• Conservez un recours humain pour les situations mal maîtrisées.
• Élargissez l’usage seulement lorsque les résultats le justifient.

Si les modèles ouverts permettent d’obtenir le résultat attendu à moindre coût total, vous disposez d’un argument concret pour les adopter. Si les corrections absorbent le gain, réduisez le périmètre ou changez de solution. Votre prochain investissement peut alors partir d’un besoin vérifié et d’un travail déjà mieux compris.

Entretien de Y Combinator avec Jeffrey Morgan, cofondateur et dirigeant d’Ollama, publié le 4 septembre 2026.

Une économie sur le calcul ne devient une économie pour l’entreprise que si le travail est réellement terminé.

Savoir reconnaître une tâche réussie devient une compétence centrale pour choisir son IA.

▶

Voir l’épisode original sur YouTube : Y Combinator.

Sources

• Y Combinator — Les modèles ouverts changent l’économie de l’IA — Entretien avec Jeffrey Morgan, publié le 4 septembre 2026. Le chiffre relatif à Ollama Cloud provient de la présentation fournie par la chaîne. Repères du chapitrage : 03:31, croissance des volumes ; 31:35, modèle unique et orchestration. Transcription intégrale non consultée : les attributions reposent sur la présentation et le chapitrage fournis.
• Ollama — Exécution des modèles sur des serveurs distants — Documentation officielle sur l’utilisation de modèles hébergés par Ollama.
• Ollama — Foire aux questions — Documentation officielle sur l’exécution locale et la désactivation des fonctionnalités distantes.