Faut-il attendre que l’IA se stabilise avant d’investir ?

L’argument de l’attente est solide en apparence. Les performances progressent, les prix changent, de nouvelles fonctions apparaissent et les comparaisons vieillissent vite. Une solution choisie aujourd’hui peut sembler dépassée quelques mois plus tard.

La mesure des gains reste elle-même instable. En février 2026, METR a expliqué que sa nouvelle expérience sur la productivité des développeurs ne permettait plus d’estimer proprement l’effet des outils d’IA. La sélection des participants et des tâches, l’usage parallèle de plusieurs agents et les différences de qualité rendaient le signal difficile à interpréter. Le constat important n’est pas que l’IA ne produit aucun gain. Il est que le gain dépend fortement de la tâche, de l’utilisateur, du système de travail et de la façon de mesurer le résultat.

Les travaux DORA sur le développement logiciel aboutissent à une conclusion comparable : l’IA agit comme un amplificateur. Elle peut augmenter le débit, mais une organisation fragile peut payer ce gain par davantage d’instabilité. L’outil n’efface pas les défauts du système ; il peut les accélérer.

Attendre peut donc être rationnel lorsqu’un projet exige un engagement lourd, repose sur une promesse encore non vérifiée ou transfère trop de pouvoir à un fournisseur. Mais l’attente a aussi un coût.

Une entreprise qui ne lance aucun travail sur l’IA ne conserve pas simplement sa position. Elle retarde quatre apprentissages qui prennent du temps, même lorsque les outils deviennent meilleurs.

1. Comprendre les processus réels. Les procédures officielles décrivent rarement les exceptions, les données manquantes et les arbitrages que les équipes réalisent chaque jour.

1. Rendre le contexte exploitable. Définitions métier, sources de référence, droits d’accès et règles de décision ne deviennent pas cohérents par l’achat d’un nouveau modèle.

1. Apprendre à évaluer. Une entreprise doit définir ce qu’est un résultat acceptable, constituer des cas de test et mesurer les erreurs qui comptent réellement.

1. Former le jugement. Les équipes doivent apprendre quand utiliser l’IA, quand vérifier, quand refuser et quand escalader.

Ces capacités restent utiles lorsque le fournisseur ou le modèle change. Elles représentent donc un investissement moins exposé à l’obsolescence que l’achat précipité d’une plateforme complète.

Notre position chez Atalas est la suivante : il faut attendre pour les engagements irréversibles, pas pour l’apprentissage réutilisable.

La décision n’oppose pas seulement « investir » et « attendre ». Trois trajectoires sont possibles.

1. Construire une option réversible

Cette trajectoire convient lorsque le problème paraît important, mais que la solution reste incertaine. L’entreprise mène une expérimentation bornée sur des données représentatives, avec une durée, un budget et des critères d’arrêt définis.

Elle conserve les actifs produits : cartographie du processus, jeux de tests, critères d’acceptation, règles d’accès, mesure de référence et enseignements des utilisateurs. Si l’outil choisi disparaît, ces éléments restent exploitables.

2. Mettre en production un périmètre stable

Cette trajectoire convient lorsqu’un flux répétable possède un propriétaire, un volume suffisant et un résultat vérifiable. L’architecture limite les droits de l’IA, journalise les actions et prévoit un retour en validation humaine.

Le cadre du NIST sur la gestion des risques liés à l’IA propose précisément quatre fonctions — gouverner, cartographier, mesurer et gérer — qui peuvent être adaptées au contexte de l’organisation. Il ne s’agit pas d’appliquer une checklist entière, mais d’installer les pratiques proportionnées au risque et à l’usage.

3. Différer avec une condition de réexamen

Attendre devient une décision active lorsqu’elle précise ce qui doit changer pour rouvrir le dossier. Par exemple : disponibilité d’une source de données fiable, clarification réglementaire, baisse d’un coût d’intégration, nomination d’un propriétaire métier ou preuve qu’un niveau de qualité est atteignable.

Sans condition ni date de réexamen, l’attente devient une non-décision. Avec des seuils explicites, elle protège le capital tout en maintenant l’option ouverte.

Il n’existe pas de prix moyen sérieux pour « un projet IA ». Deux projets utilisant le même modèle peuvent avoir des coûts très différents selon les données, les intégrations, les droits accordés et le niveau de contrôle attendu.

Le dirigeant peut comparer les trajectoires avec cinq postes :

1. Préparation : cartographie du processus, accès aux données, nettoyage et cas de test.

1. Construction : configuration, développement, intégrations et interface.

1. Validation : revue métier, sécurité, conformité, tests d’erreur et mesure du résultat.

1. Exploitation : licences ou consommation, surveillance, traitement des incidents, mises à jour et support.

1. Sortie : export des données, documentation, reprise par une autre équipe et coût de changement de fournisseur.

Le calcul utile compare ensuite le coût complet à la valeur annuelle protégée ou créée, mais aussi au coût du retard. Une option réversible peut être rentable même si elle n’automatise encore rien : elle réduit l’incertitude sur une décision plus importante. À l’inverse, un pilote peu coûteux peut être un mauvais investissement s’il ne produit ni preuve, ni apprentissage réutilisable, ni décision.

Imaginons une PME dont les équipes répondent chaque semaine à des demandes de disponibilité et de délai à partir de plusieurs systèmes. La direction envisage un agent capable de préparer une réponse.

Une décision précipitée consisterait à choisir la plateforme la plus démonstrative et à connecter immédiatement toutes les sources. Une décision d’attente consisterait à reporter le sujet jusqu’à ce que les agents soient « fiables ».

Une option réversible ferait autrement : sélectionner un type de demande, constituer un jeu de cas réels anonymisés, identifier les sources qui font foi, mesurer le temps de préparation actuel et définir les erreurs inacceptables. L’agent préparerait une réponse sans pouvoir l’envoyer. Après quelques semaines, la direction disposerait de faits : part des cas traitables, temps de revue, causes d’échec, coût d’intégration et charge d’exploitation.

Cet exemple est fictif. Il ne constitue ni un résultat client ni une promesse de performance. Il montre seulement comment transformer une incertitude technologique en décision bornée.

La réversibilité n’élimine pas tous les risques.

• Les intégrations créent des dépendances. Même avec des données exportables, reconstruire un workflow peut être coûteux.

• La qualité peut se dégrader. Un changement de données, de modèle ou de comportement utilisateur impose une surveillance continue.

• Le contrôle consomme des ressources. Vérifier, documenter et traiter les exceptions fait partie du coût réel.

• La conformité évolue. Dans l’Union européenne, les obligations de gouvernance et celles relatives aux modèles d’IA à usage général sont déjà applicables depuis août 2025, tandis que le calendrier des règles sur les systèmes à haut risque continue d’être précisé. Un projet doit suivre son régime réel plutôt qu’un résumé figé.

• L’apprentissage n’est pas automatiquement transférable. Il faut conserver les critères, les tests et les décisions dans des formats utilisables hors de l’outil choisi.

Le principal risque n’est donc pas seulement d’investir trop tôt. C’est d’investir sans savoir ce que l’entreprise doit posséder à la fin.

Choisissez un seul investissement IA actuellement discuté et classez-le selon les quatre dimensions : valeur du problème, coût du retard, réversibilité et capacité d’exploitation.

Puis tranchez entre trois actions :

1. lancer une option réversible avec un budget et une date de fin ;

1. mettre en production un périmètre stable avec un propriétaire et des contrôles ;

1. différer jusqu’à une condition explicite, avec une date de réexamen.

Si le désaccord porte sur le scénario économique, les dépendances ou le coût d’attendre, le Conseil stratégique Atalas peut structurer les trajectoires, leurs hypothèses et les signaux qui permettent de réviser la décision.

Attendre la stabilité de toute l’IA revient à attendre que le marché cesse de bouger. La discipline consiste plutôt à avancer sans confondre vitesse et irréversibilité.

Une PME a-t-elle intérêt à attendre que les grands groupes essuient les plâtres ?

Elle peut laisser les grands groupes absorber certains coûts d’infrastructure, mais elle ne peut pas leur déléguer l’apprentissage de ses propres processus, données et critères de qualité. Une PME peut commencer par une option étroite et réversible sans reproduire un programme de grande entreprise.

Quelle durée donner à une expérimentation ?

La durée doit permettre de couvrir un volume représentatif et les exceptions importantes. Elle dépend donc de la fréquence du processus, pas d’un nombre universel de semaines. La date de fin et les critères de décision doivent être fixés avant le lancement.

Comment éviter de choisir un fournisseur qui sera dépassé ?

Il est impossible de garantir quel fournisseur restera le meilleur. L’entreprise peut en revanche protéger ses actifs : données exportables, prompts ou règles documentés, cas de test, résultats mesurés, interfaces explicites et conditions de sortie contractuelles.

Un pilote sans mise en production est-il forcément inutile ?

Non. Il est utile s’il réduit une incertitude importante et débouche sur une décision. Il devient du gaspillage lorsqu’il ne laisse ni mesure, ni apprentissage réutilisable, ni critère pour poursuivre ou arrêter.

Faut-il attendre les prochaines règles européennes avant de lancer un projet ?

Pas systématiquement. Il faut qualifier l’usage, les personnes affectées, le niveau de risque et les obligations déjà applicables. Pour un projet exposé à une règle encore en évolution, une expérimentation sans décision automatisée ni déploiement irréversible peut préserver l’apprentissage tout en limitant l’exposition.