Reprendre un projet IA développé par une autre équipe : l'audit de la première semaine

---

title: "Reprendre un projet IA développé par une autre équipe : l'audit de la première semaine" seoTitle: "Reprendre un projet IA : l'audit de J1 à J5" description: "Vous héritez d'un projet IA que vous n'avez pas écrit, sans documentation ni chiffres. Voici l'audit en cinq jours qui produit un verdict défendable : ce qui marche, ce que ça coûte, ce qu'on garde et ce qu'on réécrit." seoDescription: "Hériter d'un projet IA sans documentation : l'audit en cinq jours qui dit ce qui marche, ce que ça coûte et ce qu'il faut réécrire." date: "2026-09-15" author: "Équipe Raicode" tags: ["IA", "automatisation", "architecture", "gestion de projet"] category: "IA & Automatisation" keywords: ["reprendre un projet IA", "audit projet IA", "reprise de projet IA", "transfert agence IA", "passation projet IA", "hériter d'un projet LLM", "auditer une intégration LLM", "maintenance projet IA", "coût projet IA existant"]

Le contrat avec l'agence s'est arrêté fin juin. Le développeur qui tenait la partie IA est parti en août. Il reste un dépôt Git, un espace Notion à moitié rempli, une clé d'API dont personne ne connaît le propriétaire, et une fonctionnalité en production que quarante personnes utilisent tous les jours. Votre direction vous demande, pour vendredi, si on peut continuer avec ça.

C'est la situation la plus fréquente parmi les reprises qu'on nous confie, et c'est aussi celle où l'on perd le plus de temps à se tromper de méthode. Le réflexe naturel consiste à ouvrir le code et à lire. Au bout de trois jours, on a une opinion sur la qualité du code et toujours aucune réponse aux trois seules questions qui décident de la suite : est-ce que ça marche vraiment, combien ça coûte réellement, et est-ce qu'on peut le faire évoluer sans tout casser. Un audit de projet IA n'est pas un audit de code avec un chapitre IA en plus. Les actifs qui portent la valeur — et les risques — ne sont presque jamais dans le dépôt.

Ce que vous reprenez n'est pas seulement du code

Sur une application web classique, le code contient à peu près tout ce qui compte. Sur un projet à base de LLM, il contient peut-être 40 % de la valeur. Le reste se répartit entre trois actifs invisibles.

Le premier, c'est la chaîne de préparation des données : ce qui a été extrait, nettoyé, découpé, filtré, et surtout les règles métier écrites à la main qui ont fait passer le système de « ça sort n'importe quoi » à « ça sort quelque chose d'utile ». Ces règles sont rarement documentées et souvent éparpillées entre un script, une variable d'environnement et une conversation Slack disparue.

Le deuxième, c'est la définition de la qualité : la liste des cas que le système doit traiter correctement, et la manière de vérifier qu'il le fait. Dans 80 % des reprises, cet actif n'existe pas. Personne n'a jamais écrit ce qu'était une bonne réponse. On le découvre le jour où l'on change une ligne de prompt et où plus personne ne sait dire si le changement améliore ou dégrade.

Le troisième, c'est le modèle économique de la fonctionnalité : le coût par interaction, le volume réel, et donc la marge. Il n'apparaît dans aucun fichier. Il se reconstitue à partir de la facturation du fournisseur et des logs, quand il y a des logs.

L'audit de la première semaine consiste donc à mesurer ces trois actifs, pas à juger l'élégance du code. Nous détaillons ailleurs les six murs qui séparent un prototype d'une mise en production réussie — pourquoi un POC IA validé ne passe pas en production reste la meilleure grille de lecture pour comprendre ce que l'équipe précédente a regardé et ce qu'elle n'a pas regardé. Si le sujet est chez vous une décision engageante plutôt qu'une curiosité, notre offre de reprise de projet IA correspond exactement à ce cadre : cinq jours pour produire un verdict chiffré, avant tout engagement de refonte.

Jour 1 — Inventaire des accès, du périmètre et des propriétaires

Le premier jour ne touche pas au code. Il répond à une question bêtement administrative : de quoi êtes-vous réellement propriétaire ?

Listez chaque service externe et, pour chacun, le compte qui le détient. Le fournisseur de modèle (OpenAI, Anthropic, Mistral, Azure, Bedrock), la base vectorielle, l'hébergeur, la base de données, le stockage objet, les outils d'observabilité, les éventuelles briques d'OCR ou de transcription. Puis, pour chaque ligne, écrivez le nom de la personne ou de l'entité sur la facture.

Trois découvertes classiques, dans l'ordre de fréquence :

• La clé d'API appartient au compte personnel du prestataire. Elle fonctionne encore parce qu'il n'a pas pensé à la révoquer. Elle cessera de fonctionner un mardi matin, sans préavis. C'est le risque le plus court à traiter et celui qu'on repousse le plus souvent.
• L'organisation du fournisseur de modèle n'a pas de second administrateur. Un seul compte peut créer une clé, lire la facturation et augmenter les quotas. Si cette personne est partie, vous êtes en lecture seule sur votre propre système.
• Les quotas sont au niveau par défaut. Le projet n'a jamais demandé de relèvement parce qu'il n'en a jamais eu besoin au volume actuel. Le jour où le volume double, vous découvrez une limite de débit dont personne ne parlait.

Sur la même journée, délimitez le périmètre fonctionnel réel. Pas celui du cahier des charges : celui que les utilisateurs emploient. Un entretien de trente minutes avec deux ou trois utilisateurs quotidiens vaut mieux que la documentation. La question utile n'est pas « est-ce que ça marche ? » mais « qu'est-ce que vous vérifiez à la main derrière ? ». La réponse dessine la carte des défaillances connues, celles que l'organisation a appris à contourner sans jamais les signaler.

Jour 2 — Le faire tourner, et le faire tourner sur du vrai

La deuxième journée mesure une seule chose : le temps qu'il faut pour obtenir une exécution complète du système sur un poste neuf, à partir du dépôt et de la documentation fournie.

Ce délai est le meilleur indicateur unique de la santé d'un projet repris. En dessous d'une demi-journée, l'équipe précédente a travaillé proprement et la suite sera raisonnable. Au-delà de deux jours, quelque chose d'essentiel n'a pas été transmis — une variable d'environnement non documentée, un index vectoriel construit à la main et jamais reproductible, un jeu de données qui n'existe que sur le portable de quelqu'un. Ce n'est pas un détail de confort : cela signifie que vous ne pourrez pas reconstruire le système, donc pas le tester, donc pas le modifier en sécurité.

Une fois l'exécution obtenue, ne vous arrêtez pas à la démo. Prenez cinquante entrées réelles, tirées de la production, y compris celles que personne n'aime : les documents scannés, les pièces jointes de vingt mégaoctets, les demandes en anglais dans un système conçu pour le français, les champs vides. Le jeu de démonstration a été choisi pour réussir ; votre échantillon doit être choisi pour être représentatif. L'écart entre les deux taux de réussite est souvent de trente points, et c'est cet écart qui explique le malaise diffus des utilisateurs.

Jour 3 — La qualité : est-ce que quelqu'un l'a jamais mesurée ?

Cherchez, dans le dépôt, un jeu de tests de qualité : des paires entrée/sortie attendue, un script qui les rejoue, un chiffre historisé quelque part. Si vous le trouvez, la reprise est déjà à moitié gagnée et vous pouvez sauter au jour 4.

Dans la grande majorité des cas, vous ne trouverez rien, ou bien une poignée d'exemples dans un carnet Jupyter daté de la phase de prototype. La bonne réaction n'est pas de le déplorer, c'est de le construire immédiatement, parce que rien de ce que vous déciderez ensuite ne tient sans lui. Une journée suffit pour une première version utilisable : cinquante cas issus de la production, la sortie attendue écrite par quelqu'un qui connaît le métier, un script qui compare et rend un pourcentage. Ce chiffre n'a pas besoin d'être sophistiqué. Il a besoin d'exister, d'être reproductible et d'être daté.

C'est lui qui transforme toutes les discussions suivantes. « Le nouveau prompt est meilleur » devient « le nouveau prompt passe de 72 à 81 % sur le jeu de référence ». « L'agent hallucine parfois » devient « l'agent invente une référence dans 6 % des cas, tous concentrés sur les demandes multi-documents ». Nous avons décrit la méthode complète dans construire l'évaluation qui manque à votre agent IA ; en reprise, la version compacte en une journée suffit à débloquer le verdict.

Un point d'attention particulier si le système repose sur de la recherche documentaire : mesurez séparément la récupération et la génération. Un système qui « répond à côté » a presque toujours un problème en amont du modèle, et le diagnostiquer prend quelques heures quand on sait où regarder.

Jour 4 — Reconstituer le coût unitaire

Ouvrez la facturation du fournisseur sur les six derniers mois et tracez la courbe. Trois formes reviennent, et chacune raconte une histoire différente.

Une courbe plate signale un système peu utilisé : la question n'est pas le coût, c'est l'adoption. Une courbe qui croît proportionnellement au nombre d'utilisateurs est saine, et il suffit alors de calculer le coût par interaction pour savoir si le modèle économique tient. Une courbe qui croît plus vite que l'usage est le signal d'alerte : quelque chose dans le système consomme de manière non bornée — un contexte qui grossit à chaque tour de conversation, une boucle d'agent sans limite d'itérations, un réindexage complet déclenché à chaque modification.

Le chiffre à produire tient en une ligne : coût mensuel divisé par le nombre d'interactions utilisateur du mois. Comparez-le à la valeur de l'interaction pour le métier. Si le rapport est mauvais d'un facteur 2 ou 3, les leviers habituels — mise en cache, choix de modèle par tâche, réduction du contexte — le corrigent ; nous les avons chiffrés dans d'où vient la facture d'API LLM et comment la récupérer. S'il est mauvais d'un facteur 20, aucune optimisation ne sauvera la fonctionnalité telle qu'elle est conçue, et c'est une conclusion qu'il vaut mieux poser en semaine 1 qu'en mois 6.

Vérifiez aussi ce que la facture ne montre pas : le coût d'infrastructure autour du modèle (base vectorielle, stockage, calcul d'embeddings, workers), et le temps humain de vérification. Sur beaucoup de projets repris, la relecture manuelle derrière le système coûte plus cher que les appels d'API, et personne ne l'a jamais compté parce qu'elle est diluée dans le travail des équipes.

Jour 5 — Maintenabilité et verdict

La dernière journée est celle de la lecture du code, désormais guidée par quatre questions précises plutôt que par une exploration au hasard.

Où vivent les prompts ? Un prompt en dur au milieu d'une fonction, sans version ni historique, signifie que chaque modification est un pari non traçable. Un prompt dans un fichier dédié, versionné, avec ses cas de test à côté, est un actif.

Le fournisseur est-il isolé ? Cherchez combien d'endroits du code appellent directement le SDK du fournisseur. Un seul module est un bon signe. Trente appels dispersés signifient qu'un changement de modèle ou de fournisseur devient un chantier, alors que c'est précisément l'opération que vous aurez à faire.

Quelle est la date de dépréciation des modèles utilisés ? C'est la vérification la plus rentable de la semaine et elle prend dix minutes. Un projet livré il y a dix-huit mois cible souvent un modèle dont la fin de service est déjà annoncée. Cela transforme une reprise « quand on aura le temps » en reprise datée, avec une échéance imposée par le fournisseur, ce qui aide beaucoup à obtenir un budget.

Que se passe-t-il quand l'appel échoue ? Cherchez la gestion des erreurs, des délais d'attente et des reprises. Un système sans comportement défini en cas d'échec du fournisseur n'est pas en production, il est en démonstration prolongée.

Au bout de ces cinq jours, trois verdicts sont possibles, et il faut choisir explicitement. Continuer : les fondations tiennent, le coût est soutenable, il manque l'évaluation et deux ou trois garde-fous — trois à six semaines de travail. Reprendre le cœur : la chaîne de données ou l'architecture d'appel est à refaire, mais l'interface, les intégrations et la connaissance métier se gardent — deux à quatre mois, en conservant le service en état de marche. Arrêter : le coût unitaire ou le taux d'erreur rend la fonctionnalité non viable telle qu'elle est posée, et il faut revenir au besoin avant de recoder. Ce dernier verdict est rare, mais il est parfois le seul honnête, et il coûte infiniment moins cher en semaine 1 qu'en mois 9.

Les cinq signaux qui changent le verdict

Certains constats pèsent plus lourd que les autres et méritent d'être signalés à part dans votre restitution :

1. Aucun log des appels au modèle. Sans les entrées et sorties réelles, vous ne pouvez ni diagnostiquer, ni constituer un jeu d'évaluation, ni mesurer une régression. C'est la première chose à installer, avant toute correction.
2. Des données personnelles dans les prompts, sans base légale documentée. Ce n'est pas un problème technique mais il bloque la mise à l'échelle, et il est plus simple à traiter tant que le volume reste faible.
3. Un index vectoriel non reproductible. Si personne ne sait le reconstruire, il est un point de défaillance unique et il vieillit sans que rien ne le signale.
4. Un taux de vérification manuelle supérieur à 30 %. Le système ne fait pas gagner de temps, il en déplace. Le retour sur investissement annoncé n'existe pas.
5. Aucun environnement de test. Toute modification part directement en production. Aucune amélioration sérieuse n'est possible avant d'avoir corrigé cela.

Ce que vous écrivez vendredi

La restitution tient en une page et comporte cinq éléments, tous chiffrés : le taux de réussite mesuré sur cinquante cas réels, le coût par interaction et sa projection à douze mois, le délai de reconstruction du système sur un poste neuf, la liste des accès à récupérer avec leur propriétaire actuel, et le verdict parmi les trois, assorti d'une fourchette de charge.

Ce document vaut mieux qu'un rapport de quarante pages, pour une raison simple : il est décidable. Une direction peut arbitrer dessus en vingt minutes. Un audit de code, non — il produit une liste de remarques dont aucune ne dit s'il faut continuer.

La suite dépend du verdict, mais l'ordre des travaux est presque toujours le même : les logs d'abord, parce que rien ne se mesure sans eux ; le jeu d'évaluation ensuite, parce que rien ne s'améliore sans lui ; puis les coûts, puis l'architecture. Reprendre un projet IA sans cette séquence revient à optimiser à l'aveugle un système dont on ignore s'il fonctionne — ce qui est exactement ce que l'équipe précédente a fait, et la raison pour laquelle vous êtes là.

Si vous êtes dans cette semaine-là et que vous voulez un second regard sur le verdict avant de le présenter, c'est précisément ce que nous faisons.

---

Besoin d'aide pour votre projet web ? Contactez Raicode pour en discuter.