Peut-on reprendre un projet d'IA développé par un autre prestataire ?

Oui, à trois conditions : disposer du code, disposer des accès à l'infrastructure et aux comptes fournisseurs, et pouvoir comprendre ce qui a été fait. Avec ces trois éléments, une remise en route se chiffre entre trois et huit jours. Sans les accès, la récupération passe avant toute intervention technique. Dans environ un cas sur trois, refaire revient moins cher que reprendre.

Combien coûte la reprise d'un projet d'automatisation abandonné ?

Le diagnostic complet avec recommandation écrite représente trois jours, soit 1 650 € à 550 € par jour. Une remise en route d'un système sain mais dérivé va de 1 650 à 4 400 €, une reprise avec refonte partielle de 5 500 à 11 000 €, une réécriture complète d'un premier périmètre de 8 250 à 16 500 €. L'écart d'un facteur cinq à dix entre ces options justifie de faire le diagnostic avant d'engager la suite.

Comment savoir s'il faut reprendre ou refaire un projet IA ?

Quatre critères, indépendants du montant déjà dépensé. Code accessible, périmètre pertinent et taux de réussite au-dessus de 60 % : reprendre. Code illisible mais périmètre pertinent : refaire le cœur en gardant les intégrations aux logiciels métier, qui représentent souvent le tiers du budget d'origine. Accès perdus ou périmètre inadapté : refaire en réduisant. Le montant déjà payé ne doit pas entrer dans l'arbitrage.

Pourquoi les projets d'agents IA s'arrêtent-ils ?

Quatre causes dominent. Aucun budget d'exploitation n'a été prévu et la qualité s'est dégradée sans que personne le remarque. Le périmètre était trop large et le projet s'est enlisé avant la première mise en production. Le prestataire a disparu ou la relation s'est rompue. Ou le taux de réussite était insuffisant sans qu'aucun seuil de qualité ait été écrit au contrat, ce qui rend impossible de trancher.

Que faire si l'ancien prestataire ne rend pas les accès ?

Traitez ce point en priorité, avant tout travail technique. Recensez les comptes concernés, hébergement, base de données, fournisseurs de modèles, nom de domaine, puis exercez les demandes prévues au contrat. Si aucune clause de restitution n'existe, la voie amiable puis la mise en demeure sont les étapes habituelles, avec un conseil juridique selon l'enjeu. En parallèle, chiffrez l'option de reconstruction : elle vous évite de négocier en position de faiblesse.

Combien de temps prend le diagnostic d'un projet à l'arrêt ?

Trois jours : un pour l'inventaire du code, des accès, des services externes et des données, un pour mesurer le taux de réussite réel sur vingt à trente cas d'aujourd'hui, un pour chiffrer l'écart entre l'état actuel et l'état visé, avec l'option de réécriture chiffrée en face. Le livrable tient en cinq pages et doit pouvoir conclure à « n'y allez pas ».

Comment éviter que le nouveau projet s'arrête aussi ?

Quatre garde-fous. Un seuil de qualité chiffré écrit au contrat et mesuré sur un jeu de cas réels avant mise en service. Un périmètre réduit à un cas d'usage mis en production avant tout élargissement. Un budget d'exploitation prévu dès l'année une, de l'ordre d'un à trois jours par an pour un agent en service. Et un référent interne disponible deux heures par semaine, sans lequel le projet dérive quel que soit le budget.

Reprendre un projet IA laissé en plan par un autre prestataire

Par Alexandre Rastello, publié le 16 août 2026

reprise
audit
prestataire

En résumé. Un projet d’automatisation à l’arrêt se juge sur trois éléments, pas sur la qualité du code : avez-vous le code, avez-vous les accès, quelqu’un peut-il comprendre ce qui a été fait. Avec les trois, une reprise se chiffre entre trois et dix jours de diagnostic et de remise en route. Sans les accès, la question de la reprise ne se pose même pas, il faut d’abord les récupérer. Et dans un cas sur trois, la réponse honnête est de refaire plutôt que de reprendre, parce que le code hérité coûte plus cher à comprendre qu’à réécrire. Le diagnostic qui tranche prend trois jours.

Pourquoi ces projets s’arrêtent

Quatre causes, dans l’ordre de fréquence où je les rencontre.

Le projet a été livré et personne ne l’a exploité. L’agent tourne, ou plutôt il tournait. Le prestataire est parti à la mise en service, aucun budget de suivi n’avait été prévu, et six mois plus tard le taux de réussite s’est dégradé sans que personne le remarque. Le processus métier a changé, le logiciel a été mis à jour, le modèle a évolué. Ce n’est pas une panne, c’est une dérive.

Le périmètre était trop large. Vingt cas d’usage sur cinq services, un budget à six chiffres, dix-huit mois de développement. Le projet s’est enlisé avant la première mise en production et le comité de pilotage a coupé.

Le prestataire a disparu ou la relation s’est rompue. Freelance qui change de vie, agence rachetée, désaccord commercial. Le code existe quelque part, ou pas.

Ça ne marchait pas assez bien. L’agent répondait correctement six fois sur dix. Aucun seuil de qualité n’avait été écrit au contrat, donc personne ne pouvait dire si le travail était livré ou non. Le projet est mort dans une discussion sans arbitre.

Cette dernière cause est la plus évitable, et c’est aussi celle qui laisse le plus d’amertume : les deux parties sont convaincues d’être de bonne foi, et elles le sont.

Ce qu’on trouve en ouvrant le capot

Le constat récurrent, sur les reprises que j’ai faites.

Il n’y a pas de documentation. Le code existe, il fonctionne parfois, personne ne sait expliquer pourquoi. Ce n’est presque jamais de la mauvaise volonté : c’est de la documentation reportée à plus tard pendant dix-huit mois.

Les instructions données au modèle ont été modifiées trente fois sans historique. Chaque correction a été empilée sur la précédente, et le résultat est un texte de quatre pages où trois consignes se contredisent. Personne n’ose y toucher.

Aucune mesure de qualité n’existe. Pas de jeu de cas de test, pas de taux de réussite historique, aucune trace des erreurs passées. Impossible de savoir si le système marche moins bien qu’avant, ni de démontrer une amélioration après correction.

Les clés d’API sont écrites en clair dans le code, souvent au nom du prestataire. Ce point est à traiter en priorité, avant même le diagnostic technique : il s’agit d’un risque de sécurité et d’un risque de coupure.

Et les cas particuliers ont été traités par accumulation de conditions. Chaque exception rencontrée en production a produit une règle spécifique, jamais généralisée. Le code fait vingt fois la taille nécessaire et devient impossible à faire évoluer.

Le diagnostic en trois jours

Une reprise ne se chiffre pas au téléphone. Voici ce que je regarde, dans cet ordre, et ce que ça produit.

Jour un, l’inventaire. Le code et son emplacement, les accès et leur titulaire, les services externes utilisés et qui les paie, la donnée traitée et où elle est stockée. C’est une chasse au trésor, et elle réserve des surprises : un compte cloud payé sur la carte bancaire personnelle d’un ancien salarié, ça arrive.

Jour deux, l’état réel. Le système tourne-t-il encore, avec quel taux de réussite mesuré sur des cas d’aujourd’hui. Je constitue un jeu de vingt à trente cas réels et je le passe. Ce chiffre est le point de départ de tout le reste, et il n’existe presque jamais avant.

Jour trois, l’écart. Ce que le système fait aujourd’hui, ce qu’il devrait faire, et ce qui sépare les deux. Chiffré en jours de développement, avec l’alternative de la réécriture chiffrée en face.

Le livrable tient en cinq pages et se termine par une recommandation qui peut être « n’y allez pas ». Un diagnostic qui aboutit systématiquement à un devis de reprise n’était pas un diagnostic.

Reprendre ou refaire : la grille

La réponse dépend de quatre critères, pas du sentiment sur la qualité du code.

Situation	Décision probable
Code accessible, périmètre pertinent, taux de réussite au-dessus de 60 %	Reprendre. La base est saine, il manque de la finition et du suivi.
Code accessible mais illisible, périmètre pertinent	Refaire le cœur, garder les intégrations. Les connecteurs vers vos logiciels sont le travail le plus long, ils se récupèrent souvent.
Code inaccessible ou accès perdus	Refaire, après avoir tenté la récupération. Ne payez pas une rançon technique.
Périmètre inadapté au besoin réel	Refaire, en réduisant. Le problème n’était pas technique.

Le deuxième cas est le plus courant et le plus mal arbitré. Un dirigeant qui a payé 40 000 € résiste à l’idée de jeter, ce qui est humain. Mais le code hérité n’a de valeur que s’il fait gagner du temps ; s’il en coûte à comprendre, c’est un passif, pas un actif. La bonne question n’est pas « combien j’ai payé » mais « à partir d’aujourd’hui, quel chemin est le moins cher ».

La partie qui se récupère presque toujours, en revanche, ce sont les connexions aux logiciels métier. Faire parler un ERP ancien représente souvent le tiers du budget d’origine, et ce travail ne se refait pas si le code est lisible sur cette partie précise.

Ce que ça coûte

Ordres de grandeur observés, à mon tarif de 550 € par jour.

Prestation	Charge	Coût
Diagnostic complet avec recommandation écrite	3 jours	1 650 €
Remise en route d’un système sain mais dérivé	3 à 8 jours	1 650 à 4 400 €
Reprise avec refonte partielle	10 à 20 jours	5 500 à 11 000 €
Réécriture complète d’un premier périmètre	15 à 30 jours	8 250 à 16 500 €

L’écart entre la remise en route et la réécriture est d’un facteur cinq à dix. C’est précisément pour ça que le diagnostic à trois jours se rentabilise : il évite d’engager la mauvaise option.

Un point rarement dit : la reprise d’un projet existant est parfois plus chère qu’une réécriture, à périmètre égal. Comprendre le code de quelqu’un d’autre, sans documentation et sans son auteur, prend plus de temps qu’écrire le sien. Un prestataire qui vous annonce une reprise moins chère qu’une réécriture sans avoir lu le code vous vend une intention.

Les erreurs de la reprise

Reprendre sans mesurer d’abord. Sans taux de réussite de départ, vous ne pourrez démontrer aucune amélioration, et la discussion sur « est-ce que c’est mieux qu’avant » sera une discussion d’opinions.

Garder le périmètre d’origine. Un projet qui s’est arrêté était souvent trop large. Le reprendre tel quel reproduit la cause de l’échec. Réduisez à un cas d’usage, mettez-le en production, élargissez ensuite.

Négliger la récupération des accès. Tant que les comptes sont au nom de l’ancien prestataire, vous êtes suspendu à sa bonne volonté et à sa carte bancaire. Cette régularisation passe avant le travail technique.

Chercher un coupable. L’analyse des responsabilités a son utilité si un litige est engagé, elle n’a aucun effet sur la remise en marche. Ce sont deux chantiers distincts, et les mélanger ralentit les deux.

Ce dont j’ai besoin pour commencer

Une liste courte, pour qu’un premier échange soit utile.

L’accès en lecture au code, où qu’il soit. La liste des services externes utilisés, même approximative. Une vingtaine de cas réels que le système devrait traiter, avec ce qu’il devrait répondre. Le contrat d’origine, pour la clause de cession et les conditions de sortie. Et le nom de la personne, chez vous, qui connaît le mieux le processus concerné.

Le dernier point est le plus important des cinq. Un projet repris sans interlocuteur métier disponible s’arrêtera exactement comme le premier.

Si le code est perdu et les accès fermés, dites-le tout de suite : ça ne bloque pas la discussion, ça change simplement l’option de départ, qui devient une réécriture sur un périmètre réduit. Le point de départ ne bouge pas : un audit qui dit ce qui est récupérable, avant de réécrire quoi que ce soit.

Constats et ordres de grandeur issus des missions de reprise réalisées en PME, au tarif de 550 € par jour. Les charges indiquées couvrent un premier périmètre sur un processus et varient avec l’état du code et la disponibilité des accès.

Questions fréquentes

Peut-on reprendre un projet d'IA développé par un autre prestataire ?: Oui, à trois conditions : disposer du code, disposer des accès à l'infrastructure et aux comptes fournisseurs, et pouvoir comprendre ce qui a été fait. Avec ces trois éléments, une remise en route se chiffre entre trois et huit jours. Sans les accès, la récupération passe avant toute intervention technique. Dans environ un cas sur trois, refaire revient moins cher que reprendre.
Combien coûte la reprise d'un projet d'automatisation abandonné ?: Le diagnostic complet avec recommandation écrite représente trois jours, soit 1 650 € à 550 € par jour. Une remise en route d'un système sain mais dérivé va de 1 650 à 4 400 €, une reprise avec refonte partielle de 5 500 à 11 000 €, une réécriture complète d'un premier périmètre de 8 250 à 16 500 €. L'écart d'un facteur cinq à dix entre ces options justifie de faire le diagnostic avant d'engager la suite.
Comment savoir s'il faut reprendre ou refaire un projet IA ?: Quatre critères, indépendants du montant déjà dépensé. Code accessible, périmètre pertinent et taux de réussite au-dessus de 60 % : reprendre. Code illisible mais périmètre pertinent : refaire le cœur en gardant les intégrations aux logiciels métier, qui représentent souvent le tiers du budget d'origine. Accès perdus ou périmètre inadapté : refaire en réduisant. Le montant déjà payé ne doit pas entrer dans l'arbitrage.
Pourquoi les projets d'agents IA s'arrêtent-ils ?: Quatre causes dominent. Aucun budget d'exploitation n'a été prévu et la qualité s'est dégradée sans que personne le remarque. Le périmètre était trop large et le projet s'est enlisé avant la première mise en production. Le prestataire a disparu ou la relation s'est rompue. Ou le taux de réussite était insuffisant sans qu'aucun seuil de qualité ait été écrit au contrat, ce qui rend impossible de trancher.
Que faire si l'ancien prestataire ne rend pas les accès ?: Traitez ce point en priorité, avant tout travail technique. Recensez les comptes concernés, hébergement, base de données, fournisseurs de modèles, nom de domaine, puis exercez les demandes prévues au contrat. Si aucune clause de restitution n'existe, la voie amiable puis la mise en demeure sont les étapes habituelles, avec un conseil juridique selon l'enjeu. En parallèle, chiffrez l'option de reconstruction : elle vous évite de négocier en position de faiblesse.
Faut-il garder le code existant s'il est illisible ?: Uniquement s'il fait gagner du temps. Le code hérité n'a de valeur que comme raccourci ; s'il coûte plus à comprendre qu'à réécrire, c'est un passif. La partie qui se récupère presque toujours, en revanche, ce sont les connexions aux logiciels métier : faire parler un ERP ancien représente souvent le tiers du budget initial et ce travail ne se refait pas inutilement.
Combien de temps prend le diagnostic d'un projet à l'arrêt ?: Trois jours : un pour l'inventaire du code, des accès, des services externes et des données, un pour mesurer le taux de réussite réel sur vingt à trente cas d'aujourd'hui, un pour chiffrer l'écart entre l'état actuel et l'état visé, avec l'option de réécriture chiffrée en face. Le livrable tient en cinq pages et doit pouvoir conclure à « n'y allez pas ».
Comment éviter que le nouveau projet s'arrête aussi ?: Quatre garde-fous. Un seuil de qualité chiffré écrit au contrat et mesuré sur un jeu de cas réels avant mise en service. Un périmètre réduit à un cas d'usage mis en production avant tout élargissement. Un budget d'exploitation prévu dès l'année une, de l'ordre d'un à trois jours par an pour un agent en service. Et un référent interne disponible deux heures par semaine, sans lequel le projet dérive quel que soit le budget.

Cet article fait partie du dossier Combien coûte un agent IA en 2026 : TJM, forfait et coût par requête.