Reprise de projet informatique : dois-je tout reprendre à zéro ?

5 signaux qui distinguent une dérive d'un simple retard

Tous les projets prennent du retard. Peu partent en dérive. La différence tient à la capacité de l'équipe à dire où elle en est et à le prouver. Voici les signaux qui comptent, avec la vérification à mener pour chacun.

Le reste à faire ne diminue plus

Chaque point d'avancement annonce 80 % depuis 3 mois. Les tâches terminées reviennent en anomalie. Ce n'est pas un retard, c'est une perte de contrôle sur le périmètre. Un projet en retard sait dire ce qui reste. Un projet en dérive ne sait plus.

La vérification :

Demandez la liste des éléments livrés en production, pas l'avancement en pourcentage.
Vous ne pouvez ouvrir aucun environnement par vous-même

Pas de recette accessible, pas de démonstration sans le prestataire au clavier, pas de lien que votre métier peut tester un mardi matin. Quand la seule preuve de travail est une réunion, vous achetez un récit et non un logiciel.

La vérification :

Demandez une URL de recette avec vos propres comptes, mise à jour à chaque livraison.
Chaque correction en casse une autre

Le symptôme est mécanique. Il pointe le plus souvent une absence de tests automatisés et un code où les responsabilités sont mélangées, parfois des spécifications contradictoires empilées sans arbitrage. Dans tous les cas, la conséquence est financière : le coût de chaque évolution augmente et personne ne sait dire de combien.

La vérification :

Demandez la liste des anomalies rouvertes sur les 3 derniers mois, avec la date de première correction. Le taux de couverture de tests, lui, se gonfle en une journée.
Une seule personne sait faire tourner le projet

Un développeur détient l'installation, les mots de passe et les raisons de chaque choix. Son départ, ses congés ou un désaccord commercial suffisent à vous priver de toute capacité de correction et de déploiement. Le service continue de tourner jusqu'au premier incident. C'est ce jour-là que la facture arrive.

La vérification :

Faites installer l'environnement de développement par quelqu'un d'autre, en conditions réelles.
Le discours passe des dates aux technologies

Les réunions ne parlent plus d'usage métier ni de mise en service. Elles parlent d'architecture, de refonte, de migration nécessaire. Cette bascule signale souvent qu'une impasse technique est traitée sans vous. Elle finit par vous être présentée comme un budget supplémentaire.

La vérification :

Ramenez chaque sujet technique à la question : quel utilisateur en bénéficie, et quand ?

3 signaux qui font paniquer pour rien

Le projet a pris du retard

Un retard annoncé, expliqué et re-planifié est un projet normal. La dérive commence quand le retard n'est plus explicable.

Les utilisateurs trouvent l'interface moche

Un problème d'interface se corrige. Il ne dit rien de la solidité du socle ni de la capacité du prestataire à livrer.

On vous dit que la technologie est un mauvais choix

Le vrai test n'est pas la préférence, c'est le support : la version majeure est-elle maintenue, la documentation existe-t-elle, trouve-t-on des gens qui savent l'écrire. Si oui, le débat coûte plus cher que la dette. Si non, ce n'est plus une question de goût.

Les premières 48h : sécuriser avant de négocier

Votre priorité change dès que l'hypothèse d'une rupture est sur la table : ce n'est plus le planning. Elle est de vous assurer que votre entreprise garde la main sur ses actifs. Distinguez ce qui dépend de vous et ce qui dépend du prestataire : l'inventaire des comptes, des abonnements et des points de dépendance se fait seul, en 48 heures. Les transferts et la copie se demandent au titre du contrat en cours et prennent plusieurs jours.

Reprendre la propriété des comptes

Hébergeur, nom de domaine, dépôt de code, base de données, supervision, messagerie technique. Objectif : chaque compte au nom de votre entreprise, avec votre facturation et votre authentification forte. Lancez les demandes tout de suite, mais comptez plusieurs jours pour un compte cloud et jusqu'à 60 jours de verrou sur un nom de domaine après un changement de titulaire.

Obtenir une copie complète

Le dépôt de code avec tout son historique, un export de la base de production et les fichiers stockés. Une copie sans historique perd les raisons des choix passés. Sur des données personnelles ou de santé, cet export est un traitement à part entière : destination chiffrée sous votre contrôle, accès nominatif, durée de conservation fixée et trace écrite.

Inventorier ce que le prestataire paie

Certificats, services tiers, clés d'API, licences, abonnements. Chaque ligne payée par lui devient une coupure possible, avec sa date d'échéance.

Ne rien annoncer avant d'avoir vérifié

Une rupture notifiée avant la récupération transforme un désaccord commercial en interruption de service. Vérifiez d'abord que la copie fonctionne chez vous, sur votre propre environnement.

Garder un levier

Les prestations non soldées sont souvent votre seul moyen de pression. Ne réglez pas le dernier appel de fonds avant d'avoir vérifié ce que vous avez récupéré. Faites valider la démarche par votre conseil avant de suspendre un paiement : une suspension mal fondée se retourne contre vous.

À qui appartient le code que vous avez payé ?

C'est la question qui bloque le plus de reprises, et celle que personne ne pose avant d'en avoir besoin. Le paiement d'une prestation ne transfère pas automatiquement les droits patrimoniaux sur le logiciel produit.

Un salarié: Le code de la propriété intellectuelle prévoit que les droits patrimoniaux sur les logiciels créés par un employé dans l'exercice de ses fonctions sont dévolus à l'employeur, sauf dispositions ou stipulations contraires.

Un prestataire externe: Aucune dévolution automatique. Il faut une cession écrite, c'est-à-dire un transfert écrit des droits patrimoniaux sur le logiciel. Faites-la rédiger comme l'exige l'article L.131-3 : mention distincte de chaque droit cédé, domaine d'exploitation délimité quant à son étendue, sa destination, son lieu et sa durée. La jurisprudence est partagée sur le caractère obligatoire de ce formalisme pour un logiciel. Raison de plus pour ne pas en dépendre.

Être propriétaire ne suffit pas à être autonome

Relisez votre contrat au-delà de la clause de cession. Une cession bien rédigée règle la question des droits, mais elle ne garantit ni la livraison effective du code source, ni la documentation, ni les moyens de le faire tourner. Lisez attentivement les 3 points suivants :

La livraison du code source. Un contrat peut céder des droits sans organiser la remise du code et des éléments nécessaires à sa compilation. Vérifiez la clause de réversibilité, celle qui organise la récupération du code, des données, des configurations et de la documentation dans un format et un délai exploitables, y compris quand la relation se termine mal. À défaut, vérifiez l'existence d'un séquestre de code source : le code est déposé auprès d'un tiers de confiance, qui le remet au client si des conditions limitativement prévues au contrat surviennent, par exemple la défaillance du prestataire. Le séquestre se met en place à la signature, jamais pendant la crise. Il ne vaut que si le dépôt est tenu à jour et si vous avez vérifié au moins une fois qu'il compile.
Le droit de corriger les erreurs. La loi permet à la personne autorisée à utiliser un logiciel d'accomplir les actes nécessaires à son utilisation conforme à sa destination, y compris pour corriger des erreurs. L'auteur peut toutefois se réserver ce droit par contrat, et cette clause existe plus souvent qu'on ne le croit. Attention : ce droit de corriger n'emporte aucun droit d'obtenir le code source. La remise des sources se joue uniquement dans le contrat.
Les composants tiers. Votre application embarque des bibliothèques open source et parfois des briques propriétaires. Vous héritez de leurs licences et de leurs obligations. Un inventaire des dépendances fait partie des livrables à demander.

L'audit de reprise de projet informatique regarde 5 choses, pas seulement le code

Un projet bloque rarement pour une seule raison. Un audit qui ne regarde que la qualité du code produit un rapport juste et inutile : il dira que le code est perfectible, un constat déjà connu. La question utile est de savoir combien coûte la suite, et avec qui.

1

Le code

Lisibilité, tests, dépendances obsolètes, secrets stockés en clair, composants tiers et leurs licences. L'objectif n'est pas de noter le travail passé, mais d'estimer le coût de la prochaine évolution.
2

La production

Comment on déploie, qui a la main, ce qui est sauvegardé, ce qui a déjà été restauré. Un code correct sur une production que personne ne sait redémarrer reste un risque immédiat.
3

Les données

Modèle, qualité, volumétrie, historique récupérable. Les données survivent souvent au logiciel. Elles conditionnent la valeur de ce que vous reprenez.
4

Les décisions

Ce qui a été promis, ce qui a été construit et l'écart entre les deux. Cet écart raconte le fonctionnement du projet mieux que n'importe quel rapport d'avancement.
5

L'organisation

Qui décide côté client, qui arbitre les priorités, qui teste. Beaucoup de projets en dérive ont un vrai problème de sponsor, pas de prestataire.

Sur les projets que j'audite, un outil métier de quelques dizaines d'écrans, quelques années de vie et 1 à 3 personnes qui l'ont écrit, l'exercice tient en 1 à 4 jours. Au-delà, ou en contexte réglementé, le forfait se recadre avant de commencer. Le livrable utile n'est pas un rapport de 100 pages. C'est un verdict, un plan à 30, 60 et 90 jours, et une estimation du budget de reprise.

Demandez à l'auditeur, s'il propose de réaliser la suite, de s'engager sur ce qu'il livrera, pour quel budget et dans quel délai. Il devra alors assumer ses recommandations jusque dans leur mise en œuvre. Son rapport doit aussi vous permettre de confier les travaux à un autre prestataire si vous le souhaitez.

4 issues possibles, et comment choisir la vôtre

Prenez la décision sur les faits collectés pendant l'audit, pas sur le niveau d'agacement accumulé. Changer de prestataire n'est qu'une des issues, et parmi elles, 2 ne nécessitent pas de rupture. Lisez les 4 chemins, puis tranchez avec un seul critère : avez-vous des utilisateurs en production aujourd'hui ? Si oui, les chemins 1 à 3. Si non, le chemin 4 redevient le moins cher.

Chemin 1 sur 4
Recadrer le prestataire actuel

Le produit tourne, des utilisateurs s'en servent, le problème est le pilotage ou le contrat.

À prévoir :

Un avenant, un rythme de livraison imposé et un interlocuteur nommé de chaque côté.

Ce qui l'invalide :

Vous avez déjà recadré 2 fois sans effet mesurable.
ou
Chemin 2 sur 4
Reprendre le code en l'état

L'application est en production, le code est imparfait mais lisible, les droits sont cédés.

À prévoir :

3 à 6 semaines de stabilisation avant toute nouvelle fonctionnalité.

Ce qui l'invalide :

Aucune équipe candidate n'accepte de s'engager après avoir lu le code.
ou
Chemin 3 sur 4
Stabiliser puis réécrire par morceaux

Le socle tient, mais une partie du produit est irrécupérable ou dangereuse.

À prévoir :

Plus long qu'une réécriture annoncée, mais sans coupure planifiée. Le risque se déplace vers les bascules de données et les périodes de double écriture.

Ce qui l'invalide :

Le périmètre à réécrire grossit à chaque comité.
ou
Chemin 4 sur 4
Repartir de zéro

Pas d'utilisateurs en production, besoin jamais cadré, ou droits sur le code non cédés.

À prévoir :

Le budget dépend de 2 cas. Avec des spécifications propres et à jour, le budget d'un build neuf, sans la phase de conception puisqu'elle est déjà faite. Sans spécifications exploitables, ajoutez 2 à 6 semaines de cadrage métier selon la taille du projet. Cette fourchette reste indicative : tout dépend de la complexité.

Ce qui l'invalide :

Vous refaites le même cadrage qu'au premier tour, avec les mêmes personnes.

Un critère tranche plus souvent que les autres : l'existence d'utilisateurs en production. Une application utilisée tous les jours contient des règles métier que personne n'a écrites et que la réécriture perdra. Une application jamais mise en service ne contient que des intentions, et les intentions se réécrivent vite. Le même raisonnement s'applique au choix initial entre construire ou acheter.

Le cas DI&Care illustre le deuxième chemin : reprise du code en l'état sur un projet medtech en essai clinique, sortie de la dépendance à l'agence initiale, puis migration vers un hébergement de santé maîtrisé. La reprise a duré 7 mois, sans refonte, la stabilisation et la mise en conformité passant avant l'ouverture de nouveaux chantiers.

Ce que l'IA déplace dans cet arbitrage

La grille de décision ne se lit plus comme il y a 3 ans. À l'époque, réécrire signifiait repayer intégralement l'écriture du code. Ce poste dominait le devis et rendait la reprise de l'existant presque toujours préférable, même quand l'existant était médiocre.

Le coût d'écriture du code a baissé, mais pas partout. Le gain est net là où l'assistance travaille bien : du code nouveau, sur une base propre, à partir d'un besoin déjà décrit. C'est exactement la situation d'une réécriture depuis des spécifications. Les mesures disponibles sont beaucoup moins favorables sur du code existant et mal documenté, où l'assistance peut ralentir des développeurs expérimentés, et l'effet sur la stabilité des mises en production reste négatif quand les tests et la chaîne de déploiement ne suivent pas.

La conséquence est contre-intuitive : l'IA améliore l'option « repartir de zéro » bien plus qu'elle n'améliore l'option « reprendre l'existant ». Repartir de zéro redevient donc défendable dans des situations où cette option était exclue, en particulier quand le code hérité est dangereux ou illisible.

Ce qui a baissé: Écrire le code d'un besoin déjà décrit. Produire les tests, la documentation technique, les scripts de migration. Autrement dit la partie mécanique, celle qui se déduit d'une spécification claire.

Ce qui n'a pas baissé: Reconstituer ce que le logiciel doit faire. Les outils lisent le code et en sortent des règles candidates. Ils ne disent pas lesquelles ont été voulues, lesquelles sont un bug devenu habitude, et lesquelles doivent survivre.

Le cahier des charges devient un actif au moins aussi précieux que le code

Une spécification fonctionnelle décrit ce que le logiciel doit faire, indépendamment de la façon dont il est écrit. Quand le coût d'écriture du code baisse, elle devient l'actif qui détermine la vitesse et le prix d'une reprise comme d'une réécriture. Un projet dont les spécifications sont écrites, à jour et vérifiables se reprend ou se refait beaucoup plus vite, y compris quand le code est mauvais. Un projet dont la seule spécification est le code lui-même se paie en archéologie : des semaines passées à faire dire à un logiciel ce qu'il fait, en interrogeant les utilisateurs un par un et en testant des cas limites que personne n'a documentés.

La facture de cette archéologie est double. Elle mobilise l'équipe qui reprend, mais surtout vos propres équipes métier, celles qui ont un travail par ailleurs. C'est du temps interne, rarement budgété, et aucun outil ne le compresse vraiment.

Restent 2 verrous que les spécifications ne lèvent pas : les données à migrer, et le cadre réglementaire quand le produit est certifié ou en cours d'évaluation. Sur un dispositif médical, la question n'est pas l'état du code.

Pour votre projet, il en découle 2 conséquences pratiques :

Pendant une reprise, documenter l'existant n'est pas une tâche administrative à faire plus tard : c'est la production de l'actif qui décidera du coût de la prochaine bascule.
Sur le projet suivant, demandez des spécifications tenues à jour au même titre que le code, avec la même clause contractuelle de restitution.

La passation se joue sur le savoir non écrit

La documentation manquante se reconstitue. Ce qui ne se reconstitue pas, c'est ce que les développeurs sortants ont dans la tête : pourquoi ce contournement, quel client a demandé cette exception, quelle panne a justifié ce code étrange.

Négociez 2 à 4 semaines pendant lesquelles les 2 équipes travaillent en parallèle, et budgétez-les : sans clause de réversibilité, le prestataire sortant n'y est pas tenu et facturera. Organisez des sessions de travail enregistrées, avec l'accord des participants, plutôt que des documents à rédiger.

Les livrables à demander avant la fin du contrat

Comptes et accès transférés au nom de votre entreprise, avec la liste des personnes qui les détenaient.
Dépôt de code complet, historique inclus, avec la liste écrite de ce que le prestataire conserve et à quel titre : composants réutilisables antérieurs, sauvegardes, pièces contractuelles. Et un engagement de suppression daté pour le reste.
Procédure d'installation d'un environnement de développement, exécutée par un tiers devant vous.
Schéma d'architecture, dictionnaire de données et liste des traitements automatiques.
Procédure de déploiement et de restauration, avec une restauration réellement effectuée.
Liste des dépendances, licences, abonnements et échéances de renouvellement.
Journal des incidents connus, des contournements en place et des sujets laissés en suspens.
Spécifications fonctionnelles à jour ou, à défaut, la liste des règles métier reconstituées pendant la passation.

Si le savoir non écrit tient dans la tête d'un salarié encore en poste, la passation se prépare avant son départ : le décryptage sur la dépendance à un seul développeur décrit comment l'extraire avec l'IA, sans braquer la personne.

Si vos données sont sensibles, la reprise change de nature

Avec une reprise, vos données de production deviennent accessibles à de nouvelles personnes. Dans un contexte de santé, de finance ou de données personnelles à grande échelle, cet accès se cadre avant d'être ouvert, pas après.

Le changement de sous-traitant se documente. Contrat de sous-traitance conforme à l'article 28 du RGPD, registre mis à jour, garanties suffisantes vérifiées avant l'ouverture des accès. Si vous êtes vous-même sous-traitant, l'autorisation écrite préalable de votre client est nécessaire avant de faire entrer un nouvel intervenant. C'est ce point qui décale les calendriers.
Les copies de travail sont un risque en soi. Un export de production sur le poste d'un développeur reste un export de production. Travaillez sur des jeux anonymisés ou pseudonymisés dès que c'est possible.
Une certification ne se transmet pas. Le nouvel intervenant n'hérite d'aucun périmètre certifié, et il peut avoir besoin du sien : l'administration et l'exploitation du système d'information hébergeant les données de santé relèvent des activités couvertes par la certification HDS. Vérifiez qui héberge, qui exploite et sous quel certificat après la bascule, comme détaillé dans le guide sur l'hébergement HDS.
Les accès du prestataire sortant se ferment. Le jour où la passation se termine, la revue des comptes et la révocation des clés font partie du plan. Cet oubli est fréquent et se découvre souvent des mois plus tard.

4 phrases qui coûtent cher pendant une reprise

« On réécrit tout, ce sera plus rapide. »

Dans les dossiers qu'on me confie en reprise, cette phrase est presque toujours prononcée avant que quiconque ait lu le code en entier. La réécriture recommence par les règles métier que personne n'a documentées, celles qui ont été ajoutées après un incident. C'est le poste que tout le monde sous-estime.

« Le nouveau prestataire dit que le travail précédent est mauvais. »

C'est le diagnostic de celui qui vendra la suite. Il n'est pas forcément faux, mais il n'est pas neutre. Faites poser le diagnostic par quelqu'un qui ne réalisera pas les travaux.

« On reprend, mais sans budget de stabilisation. »

Une reprise coûte avant de produire. Si le premier jalon promis est une nouvelle fonctionnalité, le plan est déjà faux et la dette technique repart pour un tour. La dette technique, ce sont les raccourcis pris pendant le développement qui rendent les évolutions suivantes plus lentes et plus risquées. Elle n'est pas anormale en soi, mais elle devient un problème quand personne ne sait la chiffrer.

« On coupe le prestataire dès la notification. »

Vous perdez en même temps les accès, le savoir et vos moyens de négociation. Le recouvrement se prépare avant l'annonce, pas après.

Si votre direction des systèmes d'information est impliquée, associez-la au diagnostic plutôt qu'au verdict : c'est une dernière remarque, et elle touche au calendrier. Les mécanismes du blocage et la façon d'en sortir sont détaillés dans l'article sur le refus d'un outil métier par la DSI.

Parler de mon projet Auditer avant de décider

FAQ sur la reprise de projet informatique

Peut-on faire une reprise de projet informatique sans le prestataire d'origine ?

Oui, à condition d'avoir le code, les données, les accès et les droits. Sans le prestataire, la difficulté n'est pas de lire le code, c'est de retrouver les règles métier implicites. Prévoyez une phase de reconstitution de ces règles avec vos utilisateurs, en plus de la stabilisation technique.

Combien coûte un audit de reprise ?

Le détail du forfait et de son périmètre est dans la section audit plus haut. Le coût d'un audit projet tech est sans commune mesure avec le budget de reprise qu'il permet d'arbitrer.

Combien coûte une reprise de projet informatique ?

Cela dépend de ce qui est récupérable, et c'est précisément ce que l'audit chiffre. Un ordre de grandeur utile pour cadrer une discussion : en dessous de 10 000 € HT, la proposition n'est probablement pas sérieuse sur un vrai périmètre. Pour un projet réel, comptez plutôt à partir de 20 000 à 30 000 € HT. Chez moi, un build ou une reprise au forfait démarre à 10 000 € HT, périmètre fixé avant de commencer. Pour un pilotage continu après la reprise, le CTO-as-a-Service démarre à 2 900 € HT par mois.

Combien de temps avant de pouvoir livrer à nouveau ?

Sur les reprises qu'on m'a confiées, une nouvelle équipe redevient utile entre 3 semaines et 3 mois. Le facteur qui décide n'est pas la taille du code, c'est la capacité à reconstruire l'environnement et à déployer sans le prestataire sortant. Tant que ce point n'est pas acquis, aucune estimation ne tient. Promettre une nouvelle fonctionnalité dès la première semaine relève du commercial. Un correctif mis en production, en revanche, est un bon indicateur.

Le prestataire refuse de livrer le code source, que puis-je faire ?

Commencez par relire le contrat : clause de cession, clause de réversibilité, éventuel séquestre. En l'absence de clause, ne comptez pas sur le juge pour ordonner la remise de sources que personne n'a prévue. Le levier réel est commercial : ce qui reste à payer, ce qui reste à renouveler, ce que le prestataire a à perdre. Faites qualifier votre position par un avocat avant de l'utiliser, mais ne construisez pas votre plan sur une victoire contentieuse.

L'IA rend-elle la réécriture moins risquée ?

Elle la rend moins chère là où l'assistance travaille bien : du code nouveau, sur une base propre, à partir d'un besoin déjà décrit. C'est exactement la situation d'une réécriture depuis des spécifications, ce qui rouvre l'option de repartir de zéro dans des cas où elle était exclue. Les mesures disponibles sont beaucoup moins favorables sur du code existant et mal documenté, où l'assistance peut ralentir des développeurs expérimentés. Autrement dit, elle améliore l'option « repartir de zéro » plus que l'option « reprendre l'existant ». Elle ne réduit pas le travail de reconstitution du besoin, qui consomme surtout du temps de vos équipes métier.

Faut-il tout réécrire quand le code est de mauvaise qualité ?

Rarement : la qualité du code est un critère parmi 5, avec la production, les données, l'écart aux promesses et l'organisation. Un code médiocre mais couvert par des utilisateurs actifs vaut souvent mieux qu'une réécriture qui remet en jeu tout le périmètre fonctionnel.

Qui est propriétaire du code quand le contrat ne dit rien ?

Payer une prestation ne transfère pas les droits patrimoniaux. Pour un salarié, le code de la propriété intellectuelle prévoit que les droits sur les logiciels créés dans l'exercice de ses fonctions ou d'après les instructions de son employeur sont dévolus à ce dernier, sauf dispositions statutaires ou stipulations contraires. Le régime des agents publics obéit à ses propres conditions, et un développement fait hors mission échappe à cette dévolution. Pour un prestataire externe, aucune dévolution automatique : sans cession écrite, les droits restent chez lui. Faites qualifier votre cas par un avocat spécialisé.

Un projet développé en grande partie avec de l'IA change-t-il la reprise ?

Cela change surtout l'état du code que vous reprenez. Le code généré rapidement est souvent volumineux, peu testé et incohérent d'un module à l'autre, avec des choix qu'aucun développeur ne peut expliquer. La reprise est possible, mais l'audit doit se concentrer sur la sécurité, la cohérence du modèle de données et l'existence de tests, plus que sur le style du code.

Quel contrat prend le relais après une reprise ?

Souvent un contrat de maintenance applicative : une prestation confiée à un tiers pour corriger, maintenir et faire évoluer une application déjà en service.

Que faire si l'application est hébergée chez le prestataire ?

Traitez l'hébergement comme un chantier distinct de la reprise du code. Identifiez qui détient le contrat cloud, ce qui est sauvegardé, ce qui est restaurable et sous quel délai la migration est possible. S'il s'agit de données de santé, vérifiez qui héberge et qui exploite après la bascule, et sous quel certificat : une certification ne se transmet pas avec le contrat. Le détail est dans le guide sur l'hébergement HDS.

Faire auditer mon projet → Décrire ma situation

Sources

Cadre consulté pour cette version du 4 août 2026. Les références juridiques sont citées à titre d'orientation. La qualification d'une situation particulière dépend des contrats signés et relève d'un conseil juridique.