Caroline B.
Cheffe de marques
Reprise de projet web
Votre développement est payé, livré à moitié, et il attend. Une reprise de projet web reprend l'existant tel qu'il est, sans réécrire ce qui fonctionne, puis chiffre en entier ce qu'il reste jusqu'à la mise en service.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Votre projet est à l'arrêt, et l'argent engagé l'est aussi
Vous avez validé un budget, approuvé des maquettes, suivi des points d’avancement. Puis le rythme a ralenti. Aujourd’hui le développement tient sur un serveur que vous ne contrôlez pas, et votre entreprise travaille toujours comme avant.
La relation avec l’équipe en place se dégrade avant le projet. Les réponses arrivent plus tard, les points d’avancement s’espacent, et l’information qui circulait au démarrage reste maintenant chez ceux qui écrivent le code. Vous posez la question la plus simple, ce qui est terminé et ce qui reste, et la réponse tarde.
Un projet s’immobilise aussi sur sa recette. Les écrans existent, vous les ouvrez, et le compte n’y est pas. Un parcours fonctionne, le suivant s’interrompt en route, un troisième s’écarte de ce qui figurait au cahier des charges. Signer cette recette vous engage, la refuser bloque la suite, et le projet reste entre les deux.
La décision suivante réclame un montant, et ce montant n’existe nulle part. L’équipe d’origine chiffre le reste à faire depuis sa propre position, celle qui a produit le travail en cours. Un développeur consulté en urgence chiffre la prochaine tâche visible, celle qu’il peut ouvrir tout de suite. Le montant qui vous manque est ailleurs : ce qu’il faut engager, en une seule fois, pour arriver en service.
Ces situations ont chacune leur origine, et elles appellent le même geste : quelqu’un ouvre le code, établit ce qu’il contient et chiffre ce qui manque. C’est l’un des quatre chantiers que nous menons sur un développement déjà existant. Celui-ci commence par une vérification que rien ne remplace, avant toute discussion de budget : votre code redémarre-t-il ailleurs que chez celui qui l’a écrit.
Vous vous reconnaissez ?
Les points de blocage qui mènent à une reprise de développement
Ces six situations arrivent chez nous par des chemins différents.
Votre prestataire ne répond plus
Les relances restent sans retour et le code dort sur son serveur. Quand un prestataire disparaît, la récupération du code passe avant tout le reste.
Vous changez d'équipe sans arrêter le projet
La relation a cessé de fonctionner, votre calendrier tient encore. Le relais se prépare pendant que le développement continue.
La recette n'aboutit pas
Vous ouvrez les écrans livrés et le compte n'y est pas. Le projet reste bloqué entre une signature que vous refusez et une suite qui attend.
Le projet dort depuis des mois
Plus personne ne le porte en interne. Le budget est sorti, la mise en service n'a jamais eu lieu.
Le reste à faire n'a jamais été chiffré
Vous savez ce que vous avez payé. Ce qu'il faut ajouter pour ouvrir le service à vos utilisateurs reste une inconnue.
Le code est arrivé seul
Vous détenez les fichiers du développement. Le cahier des charges, la procédure de mise en ligne et les règles appliquées restent à retrouver.
Ces six points de départ mènent au même premier geste. Nous récupérons le code, nous le remettons en marche chez nous, puis nous établissons ce qui fonctionne réellement. Un projet web abandonné de longue date ouvre en plus la question de ce qui a bougé autour du code pendant l’arrêt.
NOS SERVICES
Reprise de développement : six interventions selon l'état du projet
L'état réel de votre projet décide lesquelles s'appliquent. Quand le périmètre reste flou, un audit technique préalable le tranche avant que vous engagiez la reprise.
Récupération et redémarrage du code
Nous rapatrions le code source et nous le remettons en marche sur notre propre environnement.
Recette de l'existant
Nous parcourons le livrable fonction par fonction et nous classons chacune d'elles : terminée, commencée, absente, ou différente de ce qui était commandé.
Reconstitution des écrits manquants
Cahier des charges, règles de calcul, procédure de mise en ligne. Nous les rétablissons depuis le code, les maquettes et vos échanges, sur une reprise de code sans documentation. Ce travail se chiffre à part, une fois l'ampleur du manquant constatée.
Chiffrage du reste à faire
Un montant unique pour aller jusqu'à la mise en service ; le protocole détaille plus loin les lots et leur ordre de livraison.
Achèvement du développement
Nous reprenons l'écriture là où elle s'est arrêtée et nous menons le projet jusqu'à son ouverture à vos utilisateurs.
Passage de relais
Nous organisons la sortie de l'équipe en place : les éléments à transmettre, l'ordre des transferts, la date de bascule.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Envoyez-nous votre code, nous vous dirons ce qu'il reste
Décrivez votre projet, son état d’avancement et ce dont vous disposez aujourd’hui. Nous redémarrons le code de notre côté.
Les cinq temps d'une reprise de développement
-
Vous nous transmettez le code source, le cahier des charges d'origine, les maquettes, les comptes rendus de recette et vos échanges avec l'équipe précédente. Nous en tirons deux listes : ce que vous détenez réellement, et ce qui devra se reconstituer avant tout chiffrage. Quand une équipe encore en poste doit vous céder la main, cette même ouverture organise sa sortie : ce qu'il lui reste à transmettre, l'enchaînement des transferts, et la date à laquelle le pilotage bascule vers nous.
-
Nous installons le projet sur notre environnement, nous le faisons tourner avec un jeu de données de test, et nous y publions une première modification. Cette étape répond à la question qui conditionne la suite : votre code fonctionne-t-il ailleurs que chez son auteur.
-
Nous reprenons chaque parcours utilisateur prévu au départ et nous le confrontons à ce que le code exécute. Chaque fonction ressort classée, terminée, commencée, absente ou déviante. Vous recevez ce classement écrit, et il vous appartient quelle que soit votre décision ensuite.
-
Nous chiffrons la totalité du reste à faire, jamais la seule tâche suivante. Le document donne le montant global, les lots dans lesquels le travail se découpe et leur ordre de livraison. Vous engagez ensuite le tout ou une partie.
-
Nous reprenons l'écriture, nous livrons lot par lot, puis nous ouvrons le service à vos utilisateurs. Vos demandes d'évolution démarrent après cette ouverture. Ce suivi entre dans le contrat de maintenance et d'évolution, distinct du forfait initial.
Récupérer un développement : vos questions avant de nous le confier
Le code source décide de la réponse. Ce qui tourne en ligne est le résultat produit par ce code, pas le code lui-même, et une reprise s’arrête donc là. Deux voies restent ouvertes. La première consiste à retrouver ces fichiers chez ceux qui les ont eus en main : votre hébergeur, le développeur intervenu en dernier, un ancien salarié qui en gardait une copie. Cette recherche vaut d’être menée avant de renoncer. La seconde consiste à reconstruire l’outil, ce qui devient un projet neuf avec son propre cadrage. Comme vu plus haut, le redémarrage du code tranche entre ces deux voies, avant le moindre chiffrage.
.Commencez par établir ce que vous détenez déjà, et où le code se trouve physiquement. Trois points se vérifient un par un : le compte d’hébergement, le nom de domaine, et le serveur qui garde l’historique du développement. Chacun a été ouvert par quelqu’un, à un nom précis, et la facture dit lequel. Nous dressons cet état avec vous. Ce qui est ouvert à votre nom se récupère sans passer par personne. Ce qui reste bloqué déplace la discussion vers votre contrat et vos factures, terrain qui vous appartient. Nous préparons la reprise sur ce qui est accessible pendant ce temps.
.Elle se facture à part, et pour une raison simple : ce travail dépend entièrement de ce que l’équipe précédente a laissé. Retrouver ce que fait un écran depuis le code, remonter des fonctionnalités depuis des maquettes et des échanges par mail, reconstituer une règle de calcul que personne ne sait plus expliquer, ce sont des travaux de recherche, pas des travaux de développement. Nous les chiffrons séparément, après avoir vu l’état du dossier, et vous choisissez ce que vous reconstituez. Un projet arrivé avec son cahier des charges et ses comptes rendus évite cette dépense.
.Nous regardons d’abord si le socle technique retenu par l’équipe précédente est largement répandu et documenté publiquement. Un socle courant se reprend, même quand ce n’est pas celui que nous aurions choisi au départ. Un socle marginal ou construit sur mesure par l’équipe partie pose une autre question : le travail à fournir pour l’apprendre s’ajoute au reste, et nous l’annonçons avant de nous engager.
.Le délai dépend de ce que vous nous remettez au départ. Un projet livré avec son code, ses accès et ses comptes rendus de recette demande une vérification d’écrits qui existent déjà. Un projet arrivé sans ces pièces demande d’abord la phase de recherche, celle qui remonte les fonctions depuis le code et les échanges, et le calendrier s’allonge d’autant. Cette phase de diagnostic tient le plus souvent de quelques jours à quelques semaines selon le volume de code et d’écrits à vérifier, avant que nous remettions le chiffrage lui-même. Nous vous annonçons à ce moment une date de remise du chiffrage, une fois le volume constaté, et cette date tient.
.Oui, et ce découpage convient bien quand le budget restant est contraint. Nous identifions l’ensemble de fonctions le plus petit qui rende le service utilisable par vos équipes, nous le finissons, nous le mettons en production. Le reste devient une liste ordonnée que vous engagez quand vous le décidez. Vous obtenez ainsi un outil qui sert, au lieu d’un projet qui attend son dernier lot pour exister.
.Cette question se vérifie avant la reprise, pas après. Le point de départ est votre contrat d’origine : il prévoit, ou non, une clause de cession des droits sur le code écrit pour vous, et il peut aussi comporter une clause d’exclusivité qui réserve la maintenance à l’équipe qui l’a produit. Un contrat qui cède ces droits sans réserve vous laisse libre de faire reprendre le code par qui vous voulez. Un contrat muet sur la cession, ou qui réserve la maintenance à l’équipe d’origine, déplace d’abord la discussion vers votre prestataire précédent, avant toute reprise de notre côté. Nous relisons ce point avec vous dès l’ouverture du dossier, pour le clarifier avant d’engager le reste.
. POUR ALLER PLUS LOIN
Reprise de projet web : ce qui se prépare avant de nous appeler
Ce qu’il faut réunir avant de faire chiffrer une reprise
Un chiffrage sérieux dépend de la matière que vous apportez. Rassemblez ces éléments avant le premier rendez-vous, y compris ceux qui vous semblent inutiles.
- Le code source complet, avec son historique de modifications s’il existe.
- Les accès à l’hébergement, au nom de domaine et à la base de données.
- Le cahier des charges d’origine, même dépassé, même partiellement appliqué.
- Les maquettes validées, dans leur dernière version.
- Les comptes rendus de recette et la liste des anomalies restées ouvertes.
- Les comptes ouverts chez les services extérieurs que le projet appelle.
- Vos échanges avec l’équipe précédente, y compris les fils de discussion par mail.
Cette liste sert deux fois. Elle nous donne de quoi chiffrer, et elle vous montre vos trous avant que quelqu’un d’autre les découvre. Un élément absent déplace du travail vers la reconstitution, qui se chiffre à part. Le code source reste la seule pièce sans laquelle rien ne commence. Ce que vous nous confiez à ce stade, code et accès compris, ne sert qu’à établir ce chiffrage et reste entre nous : sans devis signé de votre part, nous n’en gardons aucune copie, et vous récupérez ou faites détruire ce que vous nous aviez transmis.
Changer de prestataire en cours de projet
Un relais se prépare pendant que l’équipe en place travaille encore, et l’ordre des opérations compte plus que le moment choisi pour l’annonce.
Vérifiez d’abord que chaque compte est ouvert à votre nom, et faites ouvrir à votre nom ceux qui ne le sont pas. Récupérez ensuite une copie complète du code et de la base, en dehors du serveur de production. Demandez enfin la procédure de mise en ligne écrite, celle qui décrit comment une modification atteint le site que vos clients voient.
Ces trois éléments obtenus, la bascule devient une décision de calendrier. Sans eux, elle devient une négociation. Changer de prestataire en cours de projet se joue donc en amont de la rupture, jamais après.
Un projet arrêté ne se reprend pas là où il s’est arrêté
L’interruption laisse des traces qui ne sont pas dans le code. Elles apparaissent au redémarrage et elles surprennent les entreprises qui pensaient rouvrir un dossier intact.
Les comptes souscrits pour le projet auprès de services extérieurs expirent ou changent de conditions. Les briques publiques sur lesquelles le développement s’appuie ont avancé, et celles restées en arrière posent maintenant des questions de sécurité. Vos propres règles de gestion ont bougé, vos tarifs aussi, et votre organisation interne avec eux.
Le premier travail d’une reprise consiste à mesurer cet écart, avant de reprendre l’écriture. Nous listons ce qui a changé autour du projet et ce que chaque changement impose. Cette liste rejoint le chiffrage du reste à faire, sous une ligne à part, pour que vous voyiez ce que l’attente a coûté.
Récupérer un développement mal fait sans tout jeter
Un développement jugé mauvais se trie, et le tri se fait sur les résultats plutôt que sur l’apparence du code. Nous prenons chaque fonction, nous l’exécutons sur vos propres cas, et nous regardons ce qu’elle produit.
Une fonction qui donne le bon résultat se garde, même quand son écriture nous déplaît. Une fonction qui produit un résultat faux sur vos propres dossiers de test se réécrit, même quand son écriture paraît propre. Ce critère évite la réécriture de confort, celle qu’un développeur propose devant le travail d’un autre, et qui vous coûte sans rien vous rendre.
Ce tri produit une carte du projet : les blocs qui tiennent, ceux qui se réparent, ceux qui repartent de zéro. C’est le document qui sert à décider, et il vaut mieux qu’un avis global sur la qualité du travail reçu. Récupérer un développement mal fait devient alors un arbitrage bloc par bloc, chiffré, plutôt qu’une décision prise à l’instinct.
Un projet que n’importe quelle équipe peut reprendre après nous
Reste une question, légitime chez qui vient de vivre une reprise difficile : qu’est-ce qui garantit que la situation ne se reproduira pas avec nous.
La réponse tient dans le socle technique. Nous construisons sur des briques publiques, largement employées et documentées en dehors de nous. Une équipe extérieure qui ouvre votre projet reconnaît ce qu’elle voit, retrouve la documentation publique du socle et sait où chercher. Le coût d’entrée sur votre projet reste donc celui d’un socle qu’elle connaît déjà.
Un socle maison produirait l’effet inverse. Il ferait de nous le seul recours possible, ce qui constitue une position commerciale confortable et un risque que vous porteriez seul. Nous choisissons le socle courant, et vous gardez la liberté d’aller voir ailleurs.
