Les choix cruciaux des ingénieurs en IA souvent négligés

Construire ou acheter : un dilemme persistant pour les ingénieurs en IA

Avec l'évolution rapide des modèles de langage de grande taille (LLM), les ingénieurs en intelligence artificielle se retrouvent face à un choix complexe et crucial : doivent-ils utiliser une API, affiner un modèle open-source ou développer leur propre infrastructure ? Cette question, autrefois simple, a pris une nouvelle dimension en 2026. Selon une enquête menée par Omdia en 2025, qui a interrogé 376 parties prenantes techniques et commerciales, 95 % des répondants estiment que construire leur propre modèle offre plus de personnalisation et de contrôle. Cependant, 91 % des mêmes répondants reconnaissent que les plateformes préconstruites permettent un déploiement plus rapide. Ces deux affirmations, bien que vraies, posent un dilemme difficile à résoudre.

Concrètement, le choix dépend largement de l'échelle. Pour les entreprises traitant moins de 100 000 requêtes quotidiennes, appeler une API telle que GPT-4o Mini est généralement la meilleure option. Cela permet de bénéficier d'un faible overhead et d'une itération rapide. Cependant, lorsque le volume de requêtes dépasse un million par jour, les coûts par jeton commencent à peser lourdement sur les marges.

Une analyse de 2024 a mis en lumière un aspect souvent négligé : le personnel représente 70 à 80 % des coûts d'auto-hébergement, alors que le matériel et l'électricité ne comptent que pour 20 à 30 %. Les équipes ont tendance à sous-estimer ces coûts, ce qui conduit fréquemment à des dépassements budgétaires de l'ordre de 340 %. Ces dépassements sont généralement dus à un manque de suivi de l'utilisation par locataire et à l'absence d'attribution des coûts au niveau des requêtes, plutôt qu'au tarif par jeton lui-même.

Le verrouillage des frameworks est un autre problème qui se manifeste plus tard. Par exemple, l'inférence de génération de texte de Hugging Face est passée en mode maintenance fin 2025, obligeant les équipes qui s'étaient basées sur cette technologie à migrer vers d'autres solutions. En revanche, les équipes utilisant une API n'ont pas eu à faire face à ce type de migration forcée.

Complexité du modèle et maintenabilité : un équilibre délicat

Les ingénieurs en IA doivent également jongler avec la complexité des modèles et leur maintenabilité. Un célèbre article de Google a introduit le principe CACE : Changer quoi que ce soit change tout. Dans les systèmes d'apprentissage automatique, un petit ajustement dans une partie du pipeline peut entraîner des changements surprenants ailleurs. Cela se produit rarement avec une régression linéaire, mais est fréquent avec des ensembles et des réseaux de neurones.

La recherche sur la dette technique en machine learning montre que la dépendance aux données est plus coûteuse que la dépendance au code. Pourquoi ? Parce que les données sont plus difficiles à suivre, à versionner et à expliquer à quiconque hérite du système dans six mois. L'article original estimait que le code du modèle réel n'est qu'une petite fraction d'un système ML réel. L'essentiel réside dans les magasins de fonctionnalités, la logique de pipeline, la surveillance, les déclencheurs de réentraînement et le lien entre tous ces éléments.

En pratique, les équipes choisissent souvent un modèle plus complexe pour un gain de 2 % en précision, mais paient ce choix pendant 18 mois en temps de débogage, overhead de réentraînement et la taxe du « personne ne se souvient pourquoi nous avons fait cela ». La question à poser avant de déployer un modèle complexe est : qui en sera responsable dans un an ? Si la réponse honnête est « incertaine », c'est le point de décision.

Quantité de données contre qualité des données : le piège du marais de données

Dans le domaine du machine learning appliqué, plus de données ne signifie pas toujours de meilleures performances. Les recherches montrent qu'au-delà d'un seuil de bruit, l'ajout de plus de données de faible qualité aplatit ou dégrade la performance du modèle. Cela signifie que la relation entre la taille de l'échantillon et la précision se dégrade une fois que le bruit dépasse un certain niveau.

Le problème du « marais de données » est ce à quoi cela ressemble dans les entreprises. Les équipes collectent tout parce que le stockage est bon marché et elles supposent que cela sera utile un jour. Sans gouvernance, vous obtenez un ensemble qui prend des semaines à nettoyer, augmente les coûts de stockage et de pipeline, et ralentit l'expérimentation sans améliorer les résultats.

L'IA médicale est le cas le plus clair. De petits ensembles de données avec des étiquettes vérifiées par des experts ont systématiquement surpassé des ensembles de données plus importants avec des annotations peu fiables. Le modèle a appris les bons motifs à partir de moins de données parce que le signal était clair.

La question que je trouve plus utile en pratique est : quel est le niveau de bruit de ce que nous avons, et qu'est-ce qu'une heure de nettoyage supplémentaire nous apporte par rapport à une journée de collecte supplémentaire ?

Débit vs. latence : choisir entre batch et temps réel

L'inférence par lot et l'inférence en temps réel sont deux architectures système différentes. Choisir la mauvaise entraîne des choix d'infrastructure, de coût et d'expérience utilisateur qui sont difficiles à inverser par la suite.

L'inférence par lot consiste à générer des prédictions selon un calendrier (horaire, quotidien), qui sont ensuite stockées dans une base de données et servies à partir de là. Cette méthode est moins coûteuse, avec une infrastructure plus simple et plus facile à déboguer. Cependant, les prédictions peuvent être obsolètes.

En revanche, l'inférence en temps réel génère des prédictions à la demande, en millisecondes à quelques secondes. Bien que toujours actuelles, cette méthode est plus coûteuse en raison de la nécessité d'une disponibilité 24/7. Elle comporte également plus de pièces mobiles et est plus difficile à surveiller.

La tension au niveau du système est que des tailles de lot plus grandes donnent un débit plus élevé mais une latence plus élevée par requête. Les systèmes en temps réel utilisent une taille de lot de 1, ce qui donne de la vitesse mais peut perdre en efficacité.

L'erreur que je vois le plus souvent est que les équipes se dirigent par défaut vers le temps réel parce que cela semble plus impressionnant. Mais la plupart des problèmes commerciaux n'ont pas besoin de prédictions en moins d'une seconde. Scores de churn nocturnes, rafraîchissements hebdomadaires de recommandations, mises à jour quotidiennes de modèles de fraude. Ce sont des problèmes par lot qui sont sur-ingénierisés en tant que problèmes en temps réel, et la différence de coût à grande échelle est significative.

Le signal pratique est que si vos utilisateurs ne remarquent pas si la prédiction a 5 minutes ou 5 millisecondes de retard, utilisez l'inférence par lot au lieu du temps réel.

Ingénierie des prompts vs. affinage : deux approches distinctes

La logique décisionnelle ici est devenue plus claire au cours des derniers mois. L'ingénierie des prompts est rapide, peu coûteuse et flexible. Elle peut prendre des heures à des jours pour itérer et fonctionne bien pour la plupart des tâches, en particulier avec des modèles de pointe capables.

L'inconvénient est la fragilité, car de petits changements d'entrée produisent des sorties incohérentes, et les longs prompts avec des règles de formatage complexes ont tendance à échouer dans des cas limites.

L'affinage est coûteux au départ en calcul, préparation des données et temps d'ingénierie. Il est fiable et cohérent à grande échelle une fois le travail effectué. Un exemple réel que j'ai vu cité : l'affinage de GPT-4o pour un chatbot de support client a coûté environ 10 000 $ en calcul et 6 semaines de préparation des données. L'alternative RAG a été livrée en 2 semaines.

Mon avis sur les conseils actuels des praticiens est de commencer par les prompts. Passez à l'affinage uniquement lorsque vous atteignez des modes de défaillance que les prompts ne peuvent pas résoudre. En dessous de 100 000 requêtes, les prompts sont presque toujours le bon choix. Il a été démontré que l'affinage est rentable à volume élevé lorsque la tâche est stable et bien définie.

Une analyse de 2025 a révélé que l'optimisation des prompts avec des outils comme DSPy a surpassé l'affinage de 6 à 19 points sur certains benchmarks, en utilisant 35 fois moins de déploiements. Il semble que l'écart se réduise d'année en année. L'affinage est devenu une dernière étape dans la plupart des stacks que je vois, utilisé après que les prompts ont clairement atteint leur plafond.

Le modèle hybride est de plus en plus courant en production : un modèle affiné sur le style et le ton du domaine, combiné avec RAG pour un ancrage factuel. Les deux techniques résolvent des problèmes différents.

Automatisation vs. surveillance humaine : où tracer la ligne ?

Dans quelle mesure faites-vous confiance au modèle pour agir seul ? La question utile en production est : quel est le coût d'une mauvaise décision, et qui l'absorbe ?

L'humain dans la boucle (HITL) se situe sur un spectre. À une extrémité, les humains examinent chaque sortie de l'IA avant qu'elle n'agisse. À l'autre, une automatisation complète avec des humains surveillant uniquement les anomalies.

La plupart des systèmes de production se situent quelque part entre les deux, acheminant les prédictions à faible confiance vers des humains et laissant passer celles à haute confiance. Mais le coût opérationnel du HITL est réel : examiner chaque décision du modèle ne se développe pas.

La vérité est que l'intervention humaine en temps réel ralentit le système et l'incohérence des examinateurs dégrade la qualité des étiquettes. Le modèle de travail est le HITL sélectif : la révision humaine est déclenchée uniquement pour les cas limites, les sorties à faible confiance et les décisions à enjeux élevés.

Dans les domaines de la santé, de la finance et du droit, le HITL est souvent une exigence de conformité. Un radiologue examinant les tumeurs signalées par l'IA ou un avocat examinant des clauses contractuelles signalées par l'IA. Ce sont des cas où le coût d'une erreur est trop élevé pour être entièrement automatisé.

Une façon de penser à la répartition est que l'IA gère le volume, la vitesse et la reconnaissance de motifs, tandis que les humains gèrent l'irréversibilité. La question de conception est de savoir exactement où cette ligne doit être tracée.