Intelligence artificielle

Le POC qui ne partira jamais : les signes, dès la semaine deux

Un pilote qui échoue le fait rarement à la fin. Il le fait la deuxième semaine, en silence, et tout le monde continue trois mois.

Publié le 14 août 2026 — Algeria Agency

La démonstration s’est bien passée. Le directeur a posé trois questions, le prototype a répondu correctement aux trois, la salle a trouvé cela impressionnant, et le projet est parti pour trois mois. Il ne sera jamais mis en service, et cela se savait à la fin de la deuxième semaine.

Nous avons vu ce déroulé assez souvent pour en reconnaître les signes, et ils sont tous précoces. Aucun n’est technique : un pilote d’intelligence artificielle qui meurt ne meurt presque jamais parce que le modèle était mauvais. Il meurt parce que personne n’a répondu à une question qui ne s’est pas posée.

Cet article liste ces signes, dans l’ordre où ils apparaissent, et donne les quatre questions à poser en semaine deux pour trancher. Ce sont nos observations et pas une étude : il n’existe pas de statistique algérienne sur le sujet, et nous n’en importerons pas une d’ailleurs pour faire sérieux.

La démonstration a marché, et c’est le problème

Une démonstration se prépare. Les exemples sont choisis, l’ordre est répété, la personne qui la donne connaît les questions qui vont venir parce que ce sont celles qu’elle a préparées. Rien de tout cela n’est malhonnête ; c’est ce qu’une démonstration est.

Le problème est ce qu’elle produit dans la salle : la conviction que la partie difficile est faite. Elle vient de finir la partie visible, qui est aussi la plus facile, et la salle vient de décider d’un budget sur cette base.

Le retournement utile est de considérer qu’une démonstration réussie n’apprend rien. Elle établit que le système peut fonctionner sur des cas choisis, ce qui était probable, et elle n’établit rien sur les cas non choisis, qui sont l’essentiel du travail réel.

Ce qui apprend quelque chose est l’inverse : donner au prototype cinquante cas pris au hasard dans ce qui est réellement arrivé le mois dernier, sans en écarter aucun, et regarder ce qu’il en fait devant les gens qui les ont traités. Cette séance-là est désagréable et elle est la seule qui informe.

Ce qu’un pilote doit prouver, et ce qu’il prouve à la place

Un pilote a une seule fonction : réduire une incertitude nommée. Avant de le lancer, quelqu’un doit pouvoir dire la phrase « nous ne savons pas si… » et la finir. Sans cette phrase, le pilote ne réduit rien, il occupe.

Ce qu’il prouve à la place, presque toujours, est que la technologie existe. C’est une information dont personne n’avait besoin : elle est disponible gratuitement, en dix minutes, sur n’importe quel outil grand public. Trois mois d’équipe pour l’obtenir est le gaspillage le plus courant de ce domaine.

Les incertitudes qui méritent un pilote sont d’un autre ordre et elles sont toujours locales. Est-ce que le système comprend nos clients quand ils écrivent comme ils écrivent. Est-ce que nos données sont assez propres pour qu’il s’appuie dessus. Est-ce que nos équipes le regarderont. Aucune des trois ne se règle par une démonstration.

Le test à appliquer avant de lancer tient en une question : si le pilote réussit, qu’est-ce que nous saurons que nous ne savons pas aujourd’hui ? Une réponse vague ici est un projet qui ne se terminera pas, et le savoir coûte cinq minutes au lieu de trois mois.

Semaine deux : personne n’a encore donné de vraies données

C’est le premier signe et le plus fiable des signes précoces. À la fin de la deuxième semaine, le prototype tourne sur des données inventées, sur un export de l’an dernier, ou sur trente lignes copiées à la main. Personne n’a livré ce que l’équipe technique a demandé le premier jour.

Ce n’est presque jamais de la mauvaise volonté. C’est que sortir des données réelles demande une décision que personne n’a prise : qui a le droit de les extraire, sous quelle forme, avec quels champs retirés, et qui signe. Ces quatre questions sont exactement celles d’un projet en production, et le pilote vient de buter dessus deux semaines après son démarrage.

Le signe ne dit pas que le projet est mauvais. Il dit que l’organisation n’est pas prête à le mettre en service, parce que la mise en service demandera la même décision en plus grand. Un pilote qui n’obtient pas trente lignes réelles n’obtiendra pas un flux quotidien.

La réaction utile est de traiter cela comme le sujet plutôt que comme un retard. Arrêter le développement une semaine et régler la question de l’extraction — ce que le registre décrit, champ par champ est la même information — vaut mieux que de continuer sur des données fausses pendant deux mois.

Le jeu d’exemples ne change jamais

Deuxième signe, et il se repère à l’œil. Les mêmes six ou sept exemples circulent depuis le premier jour : ils sont dans la démonstration, dans les captures d’écran, dans le message de l’équipe technique le vendredi. Personne n’en a ajouté depuis deux semaines.

Un jeu d’exemples qui ne grandit pas signifie que personne d’extérieur à l’équipe technique n’essaie le système. Or c’est là que se trouvent les cas qui comptent : les gens du métier n’apportent pas des exemples typiques, ils apportent ceux qui les embêtent, et ce sont ceux-là qui décident si le système sert.

Il y a une variante plus difficile à voir : le jeu grandit mais toujours par la même personne. Cela produit un système excellent sur la façon de poser les questions de cette personne et médiocre sur celle de tous les autres, ce qui ne se découvre qu’à l’ouverture.

Le remède est trivial et il est presque toujours refusé pour de mauvaises raisons : mettre le prototype entre les mains de trois personnes du métier dès la deuxième semaine, même laid, même incomplet, même embarrassant. Un prototype qu’on n’ose pas montrer est un prototype qui n’apprendra rien.

Le critère de réussite n’a jamais été écrit

Troisième signe. Demandez à trois personnes du projet ce qui ferait dire que le pilote a réussi. Si vous obtenez trois réponses différentes, ou trois réponses qui commencent par « si ça marche bien », il n’y a pas de critère, et un pilote sans critère ne peut pas se terminer.

Un critère utile a une forme reconnaissable : un nombre, un seuil et une population. « Sur cent demandes réelles de livraison, le système répond seul et correctement à soixante-dix, et il transmet les trente autres sans se tromper » est un critère. « Le système est fiable » n’en est pas un.

L’absence de critère a une conséquence qui explique la plupart des pilotes qui traînent : sans seuil, aucun résultat ne permet de dire non. Chaque déception devient un ajustement, chaque ajustement demande deux semaines, et le projet devient un développement continu qui n’a jamais été décidé.

Écrire le critère après coup est possible et honnête, à une condition : l’écrire avant de regarder les résultats de la semaine. Un seuil fixé en connaissant déjà le score n’est pas un seuil, c’est une justification.

L’équipe métier n’a pas ouvert l’écran

Quatrième signe, et il se mesure sans demander à personne : regardez qui s’est connecté. Si les seules connexions au prototype viennent de l’équipe technique et de la personne qui a lancé le projet, le pilote se déroule en circuit fermé.

La raison est rarement le désintérêt. C’est plus souvent qu’ouvrir l’écran demande de quitter l’outil dans lequel ces personnes travaillent toute la journée, pour essayer quelque chose qui n’est pas encore leur travail. Un prototype qui vit dans un onglet séparé est un prototype qu’on ouvre quand on y pense, c’est-à-dire pas.

C’est aussi le meilleur prédicteur de ce qui se passera après la mise en service, et sur ce point notre observation est constante : une équipe qui n’a pas ouvert l’écran pendant le pilote ne l’ouvrira pas davantage quand il sera officiel. L’officialisation ne crée pas d’habitude, elle rend seulement l’absence d’habitude visible.

La correction consiste à amener le prototype là où le travail se fait plutôt que l’inverse — dans la messagerie qu’ils utilisent, dans l’outil qu’ils ont déjà ouvert, sur le téléphone. C’est plus de travail en semaine deux et c’est ce qui décide de tout le reste.

Les cas difficiles sont repoussés à la phase deux

Cinquième signe, et il est verbal : écoutez si la phrase « on verra ça en phase deux » revient. Notez ce qu’elle recouvre. Dans les projets qui aboutissent, elle recouvre des raffinements ; dans ceux qui n’aboutissent pas, elle recouvre les cas qui font l’essentiel du volume.

Le renvoi en phase deux est un mécanisme de confort et il fonctionne très bien : il permet au pilote de continuer à bien marcher. Il déplace la difficulté vers un moment où le budget est engagé, l’équipe est fatiguée, et l’écart entre ce qui est traité et ce qui devait l’être devient impossible à absorber.

Il y a un cas particulier propre aux systèmes qui répondent : les demandes que le prototype met de côté. Elles sont normales et elles doivent être comptées dès la deuxième semaine, parce que la pile de ce qui n’est pas traité a besoin de quelqu’un qui l’ouvre chaque matin — et c’est une personne, pas une ligne de code.

La règle que nous appliquons est de traiter le cas le plus difficile en premier, et elle est impopulaire pour une raison évidente : elle rend la démonstration moins belle. Elle donne en échange la seule information qui vaille, qui est de savoir si le projet est possible du tout.

Le budget d’exploitation n’existe nulle part

Sixième signe. Le pilote a un budget, l’équipe a un budget, et personne n’a écrit ce que le système coûtera par mois une fois en service. Ce n’est pas un oubli comptable : c’est le symptôme d’un projet qui n’a pas encore été pensé comme un service.

Les postes sont connus et se listent en dix minutes : l’usage du modèle, l’hébergement, la maintenance, et le travail humain que le système ne fait pas. Le seuil entre héberger et appeler dépend de chiffres qui n’existent pas encore en semaine deux, et ce n’est pas grave — ce qui compte est que la ligne existe, pas qu’elle soit juste.

L’absence de cette ligne prédit une chose précise : au moment de la mise en service, quelqu’un découvrira un coût mensuel qui n’était dans aucun tableau, et la décision se reprendra à zéro dans un contexte où la reprendre coûte cher. Nous l’avons vu arrêter des projets techniquement réussis.

La bonne pratique est un chiffre grossier écrit en semaine deux, à un ordre de grandeur près, avec la date. Il servira surtout à être corrigé, et sa vraie fonction est de forcer la question « et ensuite » pendant qu’elle est encore bon marché à poser.

Le signe le plus fiable : la question qui ne vient pas

Voici celui que nous regardons avant tous les autres, parce qu’il les résume. En trois semaines de réunions, est-ce que quelqu’un a demandé qui utilisera ce système un mardi ordinaire, et qui s’en occupera quand il se trompera ?

Dans les projets qui aboutissent, cette question arrive tôt et elle arrive du métier plutôt que de la technique. Elle a une forme reconnaissable : elle porte sur une personne et un moment, pas sur une capacité. « Qui répondra quand il transmettra ? » est cette question ; « est-ce qu’il sait faire des résumés ? » ne l’est pas.

Quand elle n’est jamais posée, c’est presque toujours que le projet est porté par l’intérêt pour la technologie plutôt que par un besoin. Ce n’est pas une faute, et cela produit parfois de très bons apprentissages, à condition d’être nommé — un projet d’exploration a une valeur, et il n’a pas de mise en service.

Le corollaire est plus dur : si personne ne pose la question, elle ne sera pas posée non plus après la mise en service. Le système sera livré à une organisation qui ne l’attendait pas, et il rejoindra la liste des outils que l’entreprise possède et n’ouvre pas.

Ce qui arrive quand on laisse courir

Le pilote ne s’arrête pas, et c’est ce qui le rend coûteux. Il devient une démonstration permanente, qu’on ressort quand un visiteur passe, qu’on améliore un peu avant chaque comité, et qui occupe une part d’une équipe pendant des mois sans jamais changer d’état.

Le second coût est moins visible et plus durable : il consomme la crédibilité du sujet dans l’entreprise. Après deux pilotes qui n’ont rien produit, la troisième proposition, même bonne, est reçue par des gens qui ont déjà vu ce film. Nous rencontrons régulièrement des entreprises dont le vrai obstacle est un projet d’il y a deux ans.

Le troisième est humain. Les personnes qui ont travaillé sur un projet qui n’aboutit pas savent, en général bien avant leur direction, qu’il n’aboutira pas, et elles passent des semaines à faire quelque chose dont elles ont cessé d’attendre un résultat. C’est une façon coûteuse d’occuper des gens compétents.

Arrêter tôt est donc la décision qui préserve le plus de choses, et c’est aussi la plus difficile à prendre, parce qu’un pilote qui marche bien sur ses exemples ne ressemble pas à un échec. C’est exactement ce qui rend les signes précoces utiles : ils sont visibles avant que la démonstration ne devienne le produit.

Le contrôle de la semaine deux : quatre questions

Bloquez trente minutes à la fin de la deuxième semaine et posez ces quatre questions, dans cet ordre, aux personnes du projet — sans préparer la réunion et sans annoncer les questions à l’avance.

Un : sur quelles données le système tourne-t-il en ce moment, et d’où viennent-elles exactement ? Deux : combien de personnes hors de l’équipe technique l’ont ouvert cette semaine, et combien d’exemples nouveaux sont arrivés ? Trois : quel chiffre, sur quelle population, nous fera dire que c’est réussi ? Quatre : qui l’utilisera un mardi ordinaire, et qui traitera ce qu’il met de côté ?

La règle de lecture est simple et il faut s’y tenir : deux réponses floues sur quatre, et le pilote est déjà en train de ne pas aboutir. Ce n’est pas une prédiction, c’est une description de son état présent — aucune des quatre ne porte sur l’avenir.

Ce contrôle ne demande ni outil ni prestataire, il prend une demi-heure, et son résultat le plus fréquent est de faire gagner deux mois. C’est la seule chose de cet article que nous vous demandons de faire sans nous, et c’est celle qui a le plus de valeur.

Ce que nous faisons, et ce que nous refusons

Nous cadrons un pilote autour d’une incertitude écrite et d’un seuil chiffré, avec les vraies données dès la première semaine ou pas de pilote du tout. Nous mettons le prototype dans l’outil que vos équipes ouvrent déjà plutôt que dans un écran de plus, et nous traitons le cas le plus difficile en premier, ce qui rend la démonstration moins agréable et le résultat exploitable.

Nous posons les quatre questions ci-dessus à mi-parcours, y compris quand la réponse nous coûte la suite de la mission. C’est la partie du travail qui nous a fait arrêter des projets que nous aurions pu prolonger, et c’est la raison pour laquelle nos recommandations sur les projets que nous continuons valent quelque chose.

Nous ne livrons pas de démonstration destinée à convaincre un comité. On nous le demande, la demande est compréhensible, et elle produit exactement le mécanisme décrit dans cet article : une salle convaincue par des exemples choisis, un budget engagé sur cette base, et une équipe qui découvre les vrais cas trois mois plus tard.

Et nous ne promettons aucun taux de réussite avant d’avoir vu vos données. Il dépend de leur propreté et de la variété de vos cas, deux choses que nous découvrons en même temps que vous. Un chiffre annoncé avant de regarder serait précisément le genre de chiffre qui fait démarrer les pilotes dont parle cet article.

Questions fréquentes

Combien de temps un pilote doit-il durer ?

Assez pour répondre à l’incertitude écrite au départ, et pas plus, ce qui donne en pratique quelques semaines plutôt que quelques mois. Une durée fixée à l’avance sans critère produit un projet qui s’arrête quand le calendrier le dit, ce qui n’est pas la même chose que de conclure ; un critère sans durée produit l’inverse. Il faut les deux.

Faut-il vraiment de vraies données dès le départ ?

Il faut de vraies données, nettoyées si nécessaire, et pas des données inventées. Un jeu fabriqué contient les cas auxquels celui qui l’a fabriqué a pensé, c’est-à-dire les cas faciles, et un pilote qui réussit dessus n’a rien mesuré. Nettoyer ou anonymiser est un travail légitime ; inventer ne l’est pas.

Notre pilote marche bien. Est-ce quand même un mauvais signe ?

Cela dépend entièrement de sur quoi il marche bien. S’il marche sur des cas apportés par des gens du métier, choisis par eux et pas par l’équipe technique, c’est le meilleur signe qui existe. S’il marche sur le jeu d’exemples du premier jour, il vous dit seulement que ce jeu est bien traité.

Peut-on relancer un pilote arrêté ?

Oui, et c’est souvent plus facile qu’un premier essai, à condition de reprendre ce qui manquait plutôt que ce qui a été construit. Dans presque tous les cas que nous avons vus, ce qui manquait n’était pas technique : les données, le critère, ou la personne qui devait s’en servir. Le code, lui, se réécrit vite.

Qui doit porter un pilote dans une petite entreprise ?

Quelqu’un du métier concerné, avec le temps réellement dégagé pour l’ouvrir plusieurs fois par semaine. Un pilote porté par la direction générale avance par réunions et un pilote porté par l’informatique avance sans utilisateurs ; ni l’un ni l’autre ne produit la seule chose qui compte, qui est l’usage.

Ces signes sont-ils tirés d’une étude ?

Non, et nous préférons le dire : ce sont nos observations sur les projets que nous avons menés et sur ceux que des clients nous ont décrits. Il n’existe pas de statistique algérienne sur les taux d’échec de ce genre de projet, et une étude étrangère citée comme un chiffre ici décrirait un autre marché avec l’autorité d’un nombre.

Où nous intervenons

Deux réponses floues sur les quatre questions de la semaine deux, et la question n’est plus de savoir si le pilote aboutira — elle est de savoir combien de mois il occupera avant qu’on l’admette.

Nous formulons noir sur blanc la question à laquelle l’essai doit répondre, et le nombre qui y répondra.
L’essai vit là où vos équipes travaillent déjà — leur messagerie, leur écran habituel — et nulle part ailleurs.
Nous commençons par ce qui résiste, devant les personnes qui s’en occupent aujourd’hui.

Rien ne se construit pour impressionner une salle, et un pourcentage annoncé sans avoir ouvert vos fichiers n’en serait pas un.

Commencer par l’audit gratuit Voir la page Intégrations IA sur mesure

À voir aussi

Parlons de votre projet

Un audit gratuit, sans engagement : nous regardons votre présence en ligne et nous vous disons ce qui coince.

Demander l’audit gratuit Nous écrire