Reprendre un projet IA laissé par un autre prestataire

Reprendre un projet IA laissé par un autre prestataire commence par sécuriser les accès, pas par lire le code. Dans les 48 premières heures, il faut reprendre la main sur les comptes cloud, les clés API des fournisseurs de modèles, les dépôts de code et les noms de domaine, avant qu'un accès ne se ferme ou qu'une facturation ne continue de courir sans personne pour la surveiller.

Vient ensuite l'inventaire technique : ce qui tourne réellement, ce qui est documenté, ce qui repose sur une clé API personnelle qui peut disparaître du jour au lendemain. Un système peut être en difficulté sans que personne ait mal agi : un périmètre qui a bougé, un budget qui s'est arrêté en cours de route, un contexte de marché qui a changé la donne pour l'agence qui l'a construit.

Voici le protocole, dans l'ordre, avec ce qui se garde et ce qui se jette.

Les 48 premières heures : sécuriser les accès

Quand un prestataire IA disparaît, est racheté ou cesse de répondre, la priorité absolue n'est pas technique : c'est administrative. Il faut reprendre le contrôle des comptes, des clés et des noms de domaine avant qu'un accès ne se ferme, qu'une facturation continue de courir sans surveillance, ou qu'un fournisseur tiers coupe un service faute de paiement. Cette étape se compte en heures, pas en semaines.

Dressez la liste de tout ce qui peut être coupé ou repris par un tiers, et classez-la par urgence :

Si l'ancien prestataire ne répond plus

Contactez directement les fournisseurs tiers avec vos justificatifs de facturation : un hébergeur, un registrar de nom de domaine ou un fournisseur de modèle peut engager une procédure de transfert ou de récupération de compte si vous démontrez être le client final. Ce n'est pas instantané, comptez plusieurs jours selon le fournisseur, mais c'est une voie qui fonctionne dans la majorité des cas documentés.

Si le nom de domaine ou l'hébergement a été souscrit au nom personnel du prestataire plutôt qu'au nom de votre entreprise, la situation est plus délicate juridiquement. Faites-le constater par un professionnel du droit avant d'engager une action de force, notamment si le système est critique pour votre activité.

L'ordre qui évite les mauvaises surprises

Ne coupez jamais un accès existant avant d'avoir vérifié que son remplaçant fonctionne. L'ordre correct est toujours le même : reprendre le contrôle, vérifier que le système continue de tourner avec les nouveaux accès, puis seulement révoquer les anciens. Un audit de reprise commence généralement par cette cartographie des accès avant même d'ouvrir le code, précisément pour éviter qu'une intervention ne casse un système encore fonctionnel.

L'inventaire : ce qui existe réellement

L'inventaire de reprise compare ce que le contrat initial promettait à ce qui existe réellement : code source, modèle ou prompt système, données, documentation, tests. L'écart entre les deux mesure l'ampleur du travail avant même d'envisager une correction. Dans la majorité des reprises, cet écart est plus large que ce que le dirigeant imaginait.

Cet inventaire doit aussi couvrir les données : où sont-elles stockées, sous quel format, avec quel niveau de fraîcheur. Un système RAG alimenté par une base documentaire qui n'a pas été mise à jour depuis le départ du prestataire donne des réponses de moins en moins pertinentes, sans qu'aucune erreur ne s'affiche.

Notez aussi ce que vous ne trouvez pas plutôt que de simplement le déplorer : l'absence d'un élément est une information. Pas de tests signifie que chaque modification est un pari. Pas de documentation signifie que la reprise commencera par de la rétro-ingénierie, quel que soit le prestataire qui la mène.

La baseline avant de toucher au système

Une baseline mesure comment le système se comporte aujourd'hui, avant toute correction : taux de bonnes réponses sur des cas réels, temps de réponse, coût moyen par requête, fréquence des erreurs remontées par les utilisateurs. Sans cette mesure de référence, impossible de savoir plus tard si une intervention a réellement amélioré la situation ou si elle l'a seulement déplacée ailleurs.

La méthode la plus rapide pour construire une baseline fiable : rassembler 30 à 50 cas réels tirés des logs de production ou des retours utilisateurs des dernières semaines, et mesurer comment le système actuel les traite. Ce jeu de cas devient votre référence pour comparer chaque évolution future, y compris celles menées par un nouveau prestataire.

Cette discipline vaut aussi si vous envisagez de confier la suite à un prestataire différent de celui d'origine : demandez-lui de partir de votre baseline, pas de la sienne. C'est la seule façon de vérifier objectivement qu'une intervention a produit un progrès mesurable.

Dette technique, dépendances et propriété

Ouvrir le code d'un projet IA repris révèle généralement trois choses en même temps : le niveau réel de dette technique, les dépendances qui vont poser problème à moyen terme, et un flou sur qui possède quoi. Ces trois sujets se traitent ensemble, parce qu'ils déterminent tous la marge de manoeuvre pour la suite.

Ce que la dette technique raconte sur le projet

Un appel direct à une API de LLM sans couche d'abstraction, des prompts non versionnés, l'absence de tests de non-régression, des secrets codés en dur : ces signes ne veulent pas dire qu'une équipe a mal travaillé. Ils indiquent souvent un projet livré rapidement, avec un budget serré ou un périmètre qui a changé en cours de route. C'est une réalité fréquente des projets IA, pas une faute.

Ce qui compte pour la reprise, c'est de mesurer cette dette avec méthode plutôt que de la deviner : quelles parties du système sont fragiles, lesquelles tiennent malgré tout, et quel est le coût réel de chaque correction. Une lecture structurée de la dette technique apporte précisément cela, avec une taxonomie des incidents et une priorisation, plutôt qu'une impression générale de fragilité.

Qui est propriétaire de ce que vous reprenez

En droit français, un prestataire reste par défaut propriétaire du code qu'il a écrit, même intégralement payé, sauf clause explicite de cession des droits patrimoniaux. Avant de faire réécrire ou faire évoluer massivement un système par un nouveau prestataire, vérifiez ce que dit le contrat d'origine sur ce point : sans cession claire, vous disposez d'un droit d'usage, pas d'une propriété pleine, et cela peut limiter ce qu'un tiers a le droit de modifier légalement. Notre article sur la propriété du code et du modèle IA développés sur mesure détaille les clauses à vérifier.

Les dépendances qui coûteront cher à terme

Un projet construit sur une version de modèle dépréciée, sur un framework d'orchestration abandonné par ses mainteneurs, ou sur une bibliothèque dont la licence a changé, accumule une dette qui ne se voit pas tant que rien ne casse. Repérez ces dépendances tôt : elles conditionnent souvent la décision entre réparer et réécrire, abordée plus loin dans cet article.

Les coûts d'exploitation invisibles à reprendre

Un projet IA en production génère des coûts récurrents rarement documentés dans les livrables : appels API facturés à l'usage, hébergement d'une base vectorielle, abonnement à un outil d'orchestration, licence de monitoring. Reprendre un système sans reconstituer cette facturation réelle, c'est hériter d'une charge qu'on découvre au premier relevé bancaire surprenant.

Les principaux postes à vérifier :

• Coûts d'appels aux modèles de langage, souvent indexés sur le volume réel d'usage, qui peut avoir doublé depuis la mise en production sans que personne n'ait revu le budget.
• Hébergement de la base vectorielle si elle tourne en SaaS plutôt qu'en auto-hébergement.
• Abonnements aux outils d'orchestration (plans payants de plateformes de workflow) parfois souscrits sur une carte personnelle du prestataire.
• Outils de monitoring ou d'observabilité dont l'accès peut disparaître avec le compte du prestataire.
• Licences logicielles tierces liées à un compte qui n'est pas au nom de votre entreprise.

Reconstituez la facturation des trois à six derniers mois avant d'estimer un budget de reprise. C'est souvent à ce moment qu'apparaît le véritable coût total d'exploitation du système, distinct du coût de développement initial.

Réparer ou réécrire : l'arbitrage honnête

Gartner estimait en juin 2025 que plus de 40 % des projets d'IA agentique seraient abandonnés d'ici fin 2027, principalement pour des raisons de coûts, de valeur métier floue ou de contrôles de risque insuffisants. Un système repris n'échappe pas à cette réalité : parfois, la meilleure décision n'est pas de le sauver, mais de l'arrêter ou de repartir sur un périmètre plus réaliste.

Tout reprendre n'est pas toujours la bonne réponse, et c'est une honnêteté nécessaire dès cette étape. L'arbitrage entre réparer et réécrire ne se tranche pas à l'instinct : il se chiffre, poste par poste, en comparant le coût des corrections à celui d'une reconstruction ciblée sur ce qui compte réellement pour l'usage métier.

Dans la pratique, la réponse est rarement binaire : on garde souvent la base documentaire et les intégrations qui fonctionnent, on réécrit la couche d'orchestration ou de retrieval qui pose problème. C'est précisément l'objet d'un audit technique RAG et Agents IA : établir la baseline, chiffrer les deux scénarios sur des faits mesurés, et trancher sans a priori sur ce qui doit rester et ce qui doit partir.

Si la question dépasse le système technique lui-même, par exemple si le cas d'usage initial mérite d'être requestionné avant de réinvestir, il faut reprendre le sujet depuis le cadrage stratégique plutôt que depuis le code.

Pour ne pas revivre cette situation

Une fois la reprise stabilisée, la question suivante est d'éviter de se retrouver dans la même situation avec le prochain prestataire. Trois sujets se préparent avant de signer, pas après avoir dû reprendre un système en urgence.

Notre article sur la réversibilité et la dépendance au prestataire IA détaille les clauses contractuelles qui garantissent que vous pourrez toujours récupérer code, modèles et données, quel que soit ce qui arrive au prestataire. Sur la question de la propriété abordée plus haut, à qui appartient l'IA développée sur mesure détaille ce que dit le droit français et les clauses à exiger. Et pour éviter qu'un système ne se retrouve un jour dans l'état que vous venez de reprendre, maintenir une solution IA après sa mise en production explique ce qu'il faut suivre dans la durée : drift, dépendances, montées de version des modèles.

Ces trois lectures forment une base solide avant de recontractualiser, avec ce prestataire ou avec un autre.

Questions fréquentes sur la reprise d'un projet IA

Pour aller plus loin

• Choisir un prestataire IA pour sa PME : 12 critères qui comptent vraiment : pour la prochaine sélection, une fois la reprise stabilisée.
• Pourquoi les projets IA échouent en PME : les causes récurrentes, utiles pour comprendre le contexte du système que vous reprenez.
• Garanties d'un projet IA : cadre et résultats : ce qu'il faut exiger contractuellement pour le prochain projet.
• Cahier des charges IA pour PME : méthode et modèle : pour recadrer le périmètre si vous repartez sur une réécriture.
• Confidentialité des données pour un projet IA : à vérifier en particulier si le système repris traite des données sensibles.

Prochaine étape

Si vous reprenez un système RAG ou un agent IA laissé par un autre prestataire, l'urgence n'est pas de choisir entre tout garder et tout jeter, mais de savoir sur quels faits trancher. Notre audit technique RAG et Agents IA établit cette baseline, cartographie la dette et les dépendances, et priorise les corrections, sur devis selon la taille du système.

Les résultats et recommandations restent utilisables par vos équipes ou par tout autre prestataire : l'objectif est de vous redonner la main sur votre système, pas de créer une nouvelle dépendance.