Combien de temps dure un projet IA sur mesure, semaine par semaine
Un projet IA sur mesure, du cadrage à un système en production sur un périmètre étroit, dure chez nos clients de trois à cinq mois. Le prototype qui prouve la valeur tient en 2 à 4 semaines ; le reste du calendrier est de l’évaluation, de l’intégration et de la mise en production progressive, et c’est là que les écarts entre projets se creusent. Les durées ci-dessous sont des fourchettes tirées de notre pratique, pas une statistique, et elles supposent un périmètre d’un seul workflow.
Semaines 1 et 2 : le cadrage et l’accès aux données
Les deux premières semaines servent à écrire ce que le projet doit prouver : le processus visé, son volume, la baseline mesurée, le critère de succès chiffré, le périmètre de la première version et un responsable métier nommé. Ce document de cadrage tient en quelques pages et sert ensuite de référence à chaque arbitrage.
En parallèle, nous demandons les données, export de l’ERP, dossier de documents réels, accès en lecture, et cette demande conditionne tout le calendrier. Quand les fichiers arrivent la première semaine, le prototype démarre la troisième. Quand ils arrivent après six semaines de validation interne, le projet a perdu un mois et demi sans qu’une ligne de code ait été écrite.
Semaines 3 à 6 : le prototype sur des cas réels
Le prototype prend 2 à 4 semaines, et il tourne dès le premier jour sur vos cas réels, jamais sur un échantillon choisi pour bien se comporter. Il répond à une seule question : sur votre workflow et vos données, le système bat-il la baseline ? Le responsable métier le manipule dès la deuxième semaine, en version grossière, parce que ses réactions sur des cas concrets valent plus qu’une spécification.
À la fin de cette phase, une décision est prise : continuer, réorienter ou arrêter. Un prototype qui ne bat pas la baseline et s’arrête là a coûté quelques semaines au lieu de rejoindre la liste des projets IA qui n’ont rien produit.
Semaines 5 à 10 : le jeu d’évaluation et les itérations
Le jeu d’évaluation se construit à cheval sur le prototype et la suite : quelques centaines de cas réels, annotés par le métier avec la bonne réponse, pour mesurer chaque version du système au lieu de la juger à l’œil. Constituer ce jeu demande une à deux semaines de travail côté client, et c’est le poste que les plannings oublient le plus souvent.
Viennent ensuite les itérations. Chaque modification du prompt, du modèle ou des règles se mesure contre le jeu, et une version ne remplace la précédente que si ses chiffres sont meilleurs. Deux à quatre semaines suffisent en général pour atteindre le niveau fixé dans le cadrage, à condition que les cas d’échec soient revus chaque semaine avec le métier.
Semaines 8 à 20 : l’intégration et la mise en production progressive
L’intégration aux systèmes existants dure de 2 à 6 semaines selon ce que les systèmes exposent. Une API documentée se branche en quelques jours. Un ERP sans API passe par des exports et des imports, voire un pont par l’interface, et l’écart se joue là, tout comme une partie des écarts de budget. C’est aussi le moment des droits d’accès, de la journalisation et de la supervision, qui ne relèvent pas de la finition : c’est ce chantier que les POC contournent, et qui les condamne.
La mise en production se fait par paliers, sur 3 à 6 semaines. D’abord un sous-ensemble d’utilisateurs ou de documents, avec une revue humaine sur tout ce qui sort, puis un élargissement à mesure que les métriques tiennent, le responsable métier décidant de chaque palier sur des chiffres. L’élargissement à un deuxième flux repart ensuite d’un cadrage court et va nettement plus vite, parce que la chaîne existe.
Ce qui allonge le calendrier et ce qui le raccourcit
Quatre causes expliquent presque tous les dépassements que nous avons vus. L’accès aux données, quand l’export demandé passe par trois services et une validation de la DSI. La validation juridique, quand le contrat avec le fournisseur de modèle et l’analyse RGPD n’ont pas été lancés dès le cadrage. L’intégration à un ERP sans API, qui transforme deux semaines en six. Et le comité de pilotage trop large, où chaque décision attend la réunion mensuelle : un projet de seize semaines ne survit pas à quatre réunions d’arbitrage.
À l’inverse, trois choses raccourcissent le calendrier. Un responsable métier disponible plusieurs heures par semaine, qui tranche les cas limites et annote le jeu d’évaluation. Un périmètre étroit, un seul flux, une seule équipe. Et des données déjà extraites, même imparfaites, au moment où le projet démarre. Ce sont aussi les points sur lesquels un bon prestataire vous interroge avant de signer.
Ce calendrier est à comparer avec le format qui domine encore : le POC de trois mois, mené sur un échantillon propre, présenté en comité, puis prolongé de trois mois pour "sécuriser", et qui ne sort jamais parce qu’aucune de ses phases n’a été pensée pour la production. Un projet séquencé ainsi prend à peu près le même temps et finit en production. C’est ce séquencement que nous appliquons sur les systèmes que nous construisons, avec la date de chaque palier écrite dès le cadrage.