Reprendre Reprise et modernisation d'application

Votre application fait tourner le métier. Plus personne ne sait comment.

Reprendre une application, c'est en récupérer le code et l'exploitation auprès de l'équipe qui la tenait, sans interrompre l'activité qu'elle porte. On la documente, on la sécurise, on la découpe par morceaux et on la rebranche sur le reste de vos outils. Sans l'arrêter, et sans la réécrire.

Faire auditer l'existant Le parcours de reprise

Un audit avant tout devis de refonte
Aucune mise à l'arrêt de l'activité
Le rapport d'audit vous reste

Depuis 2014

Des applications reprises, encore en service
Agence agréée

Crédit d'Impôt Innovation
Hébergement en France

et conformité RGPD
Exigences cybersécurité

Formation SecNum, référentiels ANSSI

Votre situation

Quand plus personne ne sait ce que fait votre application

Votre prestataire est parti sans rien documenter. Le code est là, les accès à moitié, et plus personne ne sait pourquoi telle règle métier existe.
On vous a chiffré une refonte complète. Le montant vous a fait reculer, et depuis rien ne bouge. Pendant ce temps l'application continue de tourner sans que personne n'ose y toucher.
Elle ne sait parler à aucun de vos autres outils. Pas d'API, pas d'export, un écran et des copies manuelles. Chaque nouveau logiciel de l'entreprise contourne celui-là.
Vous héritez d'une application après une acquisition. Vous ne l'avez pas choisie, elle tourne, et vous devez décider ce qu'on en fait sans avoir la compétence en interne pour trancher. Direction technique partagée

La première dépense utile est un audit : ce qui tient, ce qui est dangereux, et ce que coûte chaque option, avant tout devis de refonte.

Ce que vous achetez

Ce que couvre la reprise
de votre application.

L'audit passe d'abord. La modernisation vient une fois qu'on sait ce qu'on touche.

Faire auditer l'existant

La carte de l'existant Le code, l'infrastructure, les données et les flux, lus et documentés. À l'arrivée, quelqu'un sait de nouveau ce que fait votre application, et vous aussi.
La reprise des clés Dépôts, hébergement, noms de domaine, comptes tiers, licences des briques utilisées. On vérifie au nom de qui tout cela est déposé : ce qui dormait chez un prestataire que vous ne pilotez plus revient chez vous.
La mise en sécurité Sauvegardes vérifiées, mises à jour, supervision, tests sur les parcours critiques. On arrête l'hémorragie avant de parler d'évolutions.
Le découpage, zone par zone Un bloc unique dont personne ne connaît les dépendances devient des morceaux qu'on peut livrer, tester et remplacer séparément.
Et la suite, une fois la main reprise Exploitation, correctifs et évolutions dans la durée, avec un seul responsable du code jusqu'au serveur. Reprendre le tout en interne est aussi une sortie prévue.

Le parcours

Documenter, sécuriser, découper, ouvrir

Documenter On lit le code, l'infrastructure, les données et les flux, et on récupère les accès. C'est le seul lot que vous puissiez acheter seul, et il se conclut par un rapport écrit qui vous reste.
Sécuriser Sauvegardes vérifiées et restaurées pour de vrai, mises à jour, supervision, tests sur les parcours critiques. Les montées de version se reprennent une par une, en commençant par celles qui exposent la production.
Découper Le monolithe est repris par domaine métier, et chaque morceau passe en production dès qu'il est prêt. À aucun moment vous n'attendez une bascule complète pour voir un effet.
Ouvrir Des API pour vos autres logiciels, un serveur MCP quand vous voulez qu'un agent IA lise ou écrive dedans. L'application cesse d'être une impasse dans votre système d'information.

Vous pouvez vous arrêter après le premier lot et faire exécuter le plan par quelqu'un d'autre. Le rapport est écrit pour ça : il dit ce qui tient, ce qui est dangereux, et ce que coûte chaque option.

Le morceau qu'on oublie

Une application ancienne peut redevenir un fournisseur de données

Le blocage vient souvent de l'isolement de l'application : pas d'API, pas d'export, un écran et des copies manuelles. Chaque outil que l'entreprise achète ensuite la contourne, et l'écart se creuse jusqu'au jour où la remplacer paraît la seule issue. Ouvrir l'existant coûte une fraction de ce que coûte le remplacer.

Une API pour le reste de vos outils Vos données sortent et rentrent par une interface documentée, avec des droits. Le CRM, l'ERP et les tableaux de bord se branchent dessus au lieu de vivre sur des exports manuels.
Un serveur MCP pour vos agents IA La même chose, mais adressable par un agent : il lit et il écrit dans l'application avec les droits de la personne qui l'utilise, et chaque action laisse une trace. Agents IA connectés au SI
Le monolithe découpé par domaine Nous séparons ce qui doit pouvoir évoluer seul de ce qui peut rester tel quel, pour que vous puissiez livrer une zone sans risquer les autres.
Les données remises d'aplomb Doublons, incohérences, conventions que chacun s'était inventées : la reprise les met au jour. Elles sont traitées avant l'ouverture des interfaces, sinon l'API propage l'erreur.

Pourquoi nous

Nous lisons le code avant de chiffrer quoi que ce soit

Proposer de tout réécrire est la réponse la plus rapide à donner, et la plus chère à payer : elle dispense de comprendre ce que vingt personnes ont écrit avant. Lire du code qu'on n'a pas écrit est une part constante de notre activité depuis dix ans, et c'est un travail d'architecture plutôt qu'une traduction ligne à ligne.

Un architecte logiciel passé par e-TF1 Cédric Lombardot y était au pôle architecture et méthodes : construction des solutions techniques, revues de code, formation des développeurs.
Des développeurs salariés, depuis 2014 Ceux qui reprennent votre code sont ceux qui répondent quand il bouge. Ils sont en CDI et restent sur votre dossier après la reprise.
Des applications tenues sur dix ans Certaines de celles que nous avons reprises tournent encore, et nous sommes toujours dessus. Nous pouvons vous mettre en relation avec ces clients.
Le rapport vous reste Que la suite nous soit confiée ou non, vous partez avec un document exécutable par un autre prestataire, accès et arbitrages compris.

Nos réalisations

Des applications reprises, et toujours en service.

Certains clients ne peuvent pas être nommés. Leurs récits sont publiés anonymisés.

Voir tous les projets

Par où commencer

Écrit
Chiffré
Sans suite obligatoire

L'audit de reprise se chiffre en jours, sur un périmètre fermé annoncé à l'avance. Le budget de la reprise se décide après, à partir de ce qu'il a trouvé.

Faire auditer l'existant

Audit de reprise et récupération des accès
Plan de mise en sécurité
Découpage et modernisation par lots
Ouverture par API et serveurs MCP
Exploitation et évolutions dans la durée

Portrait de Cédric Lombardot, fondateur de DonkeyCode

Le dirigeant

Le dirigeant conduit lui-même l'audit.

Cédric Lombardot développe depuis 2007. Il a été architecte logiciel chez e-TF1, au pôle architecture logicielle et méthodes, où il construisait les solutions techniques, relisait le code des développeurs et les formait. Il a monté deux start-ups avant de créer DonkeyCode en 2014.

C'est lui qui mène l'audit de reprise et qui vient en défendre les conclusions devant votre direction. Sur une application critique, la décision la plus chère est celle de tout réécrire : elle se prend au vu du code, des données et de vos contraintes d'exploitation, pas à partir d'une impression sur l'âge de la technologie.

Architecte logiciel chez e-TF1

pôle architecture logicielle et méthodes
Développeur depuis 2007

et deux start-ups montées avant DonkeyCode
Agrément CII depuis 2015

Crédit d'Impôt Innovation

L'équipe

Des développeurs qui ont déjà repris ce que d'autres ont laissé

L'audit se conduit à plusieurs, chacun sur la zone qu'il devra reprendre ensuite : les données et les traitements, les parcours que vos utilisateurs empruntent tous les jours, l'infrastructure et le déploiement. Ce sont des développeurs seniors qui travaillent ensemble depuis des années, habitués aux environnements où une interruption se planifie plusieurs semaines à l'avance.

Nous travaillons avec des grands comptes et leurs exigences d'exploitation : des interruptions annoncées dans une fenêtre convenue, des sauvegardes qu'on restaure pour de vrai, des accès tracés. Celui qui lit votre code est celui qui devra le tenir ensuite, et il le lit en le sachant.

Voir toute l'équipe

Souvent menée avec

Questions qu'on nous pose vraiment

Vous allez nous proposer une refonte complète ?

Non. La réécriture complète coûte le prix du neuf, dure plus longtemps que prévu, et pendant tout ce temps l'application existante continue de tourner sans que personne n'ose y toucher. Un code ancien qui rend service depuis huit ans a prouvé quelque chose : ce qui est remplacé l'est parce que ça bloque, pas parce que c'est démodé.

Par quoi ça commence, et combien ça coûte ?

Par un audit de reprise, chiffré en jours sur un périmètre fermé annoncé à l'avance. Il se conclut par un rapport écrit que vous gardez, que la suite nous soit confiée ou non. Le budget de la reprise elle-même se chiffre ensuite, à partir de ce que l'audit a trouvé, jamais avant.

Notre application est un monolithe. Il faut passer aux microservices ?

Rarement en entier. Nous découpons par domaine métier ce qui a besoin d'évoluer seul, et nous laissons ensemble ce qui n'en a pas besoin. Le critère est de pouvoir livrer une zone sans risquer les autres. Un découpage mené trop loin remplace un problème de couplage par un problème d'exploitation.

Peut-on brancher l'application sur nos autres outils, et sur l'IA ?

C'est souvent le meilleur retour sur investissement de la reprise. On ajoute une API documentée avec des droits, et un serveur MCP quand vous voulez qu'un agent lise ou écrive dedans avec les droits de la personne qui l'utilise. Une application ancienne qui expose enfin ses données cesse d'être contournée par tous les logiciels achetés depuis.

Voir l'offre Agents IA connectés au SI

Notre prestataire est parti sans documentation. C'est bloquant ?

Non. L'audit sert précisément à reconstituer ce qui n'a jamais été écrit, à partir du code et de la production. Ce qui bloque vraiment, ce sont les accès manquants : dépôts, hébergement, noms de domaine, comptes tiers. On les récupère avant tout le reste, et cette liste fait partie du rapport.

Faut-il arrêter l'application pendant les travaux ?

Non, et c'est l'engagement de départ. La modernisation se fait par lots, zone par zone, et chaque livraison passe en production. Les rares interruptions nécessaires, sur une migration de données par exemple, sont planifiées avec vous et tiennent dans une fenêtre annoncée.

On peut continuer à sortir des évolutions pendant la reprise ?

Oui, et c'est la règle. Les corrections prioritaires et les évolutions demandées par le métier avancent dans le même flux, avec un ordre décidé avec vous à chaque cycle. Geler le produit six mois n'est jamais une option que nous proposons.

Reprise de code, code legacy, dette technique : de quoi parle-t-on ?

D'une même situation, nommée de trois façons. La reprise de code, c'est le fait de récupérer un code source écrit par quelqu'un d'autre et d'en redevenir responsable. Le code legacy, ou code hérité, désigne celui que plus personne dans l'entreprise ne sait modifier sans risque — souvent parce que ses auteurs sont partis, pas parce qu'il est ancien. La dette technique est ce que coûte chaque évolution à cause de cet état : un mois de développement là où deux semaines suffiraient. L'audit de reprise chiffre cette dette poste par poste et dit lesquels valent d'être remboursés, parce que rembourser toute la dette d'une application coûte le prix de la réécriture.

Vous reprenez n'importe quelle technologie ?

Notre terrain, ce sont les applications web. Si le code sort de ce périmètre, on vous le dit à l'audit plutôt qu'au troisième mois. Cas voisin mais différent : une application montée très vite avec l'IA, dont la reprise ne commence pas au même endroit.

Voir l'offre Rescue IA

Qui est propriétaire du code et des accès ?

Vous, du premier au dernier jour. Le code vit dans vos dépôts, l'hébergement peut être à votre nom, et nous n'introduisons rien de technique qui vous retienne chez nous. C'est aussi ce qui nous oblige à rester utiles.

Qui travaille sur notre application ?

Cédric Lombardot sur l'audit et les arbitrages, et les développeurs salariés de l'agence pour la reprise. Ceux qui reprennent le code sont ceux qui répondent quand il bouge.

Avez-vous une application dont plus personne ne connaît le fonctionnement, et que vous n'osez plus toucher ?

Dites-nous ce qu'elle fait, depuis quand, et ce que vous n'osez plus modifier. On vous dira ce que l'audit couvrirait et ce qu'il représente.

Parlons de votre projet

ou choisissez un créneau tout de suite