Le prestataire est parti
Fin de contrat, désaccord, société fermée. Vous avez peut-être le code, peut-être pas les accès, et sûrement pas la documentation.
Urgence : récupérer les accèsTMA · reprise · dette technique
Le prestataire d'origine est parti. La documentation n'a jamais existé. Chaque modification casse quelque chose ailleurs, alors on ne modifie plus rien, et l'application se dégrade doucement jusqu'au jour où elle ne se lance plus sur la dernière version d'iOS.
C'est l'une des demandes les plus fréquentes que nous recevons, et l'une de celles que nous traitons le mieux. Nous commençons toujours par un audit chiffré : vous connaissez le coût de la reprise avant de vous engager.
Avant même de parler du code, il faut vérifier ce qui est à votre nom. C'est le point qui bloque le plus souvent les reprises, et celui auquel personne ne pense avant d'en avoir besoin.
Le point de départ
Elles arrivent rarement seules : la deuxième découle souvent de la première, et la quatrième est généralement le symptôme des trois autres.
Fin de contrat, désaccord, société fermée. Vous avez peut-être le code, peut-être pas les accès, et sûrement pas la documentation.
Urgence : récupérer les accèsElle fonctionne encore, mais elle n'a pas suivi les dernières versions d'iOS ou d'Android. Les bibliothèques utilisées ne sont plus maintenues, certaines ont des failles connues. Le risque grandit sans rien casser de visible.
Risque : sécurité et compatibilitéPas de tests automatisés, une architecture qui a dérivé au fil des demandes. L'équipe a peur de livrer, donc elle livre moins, donc chaque livraison devient plus grosse et plus risquée. Le cercle est classique et il s'accélère.
Symptôme : dette techniqueVos utilisateurs demandent des fonctions, vos concurrents avancent, et chaque devis d'évolution paraît disproportionné par rapport à la demande. C'est souvent le signe que le coût de modification est devenu supérieur au coût de construction.
Coût : chaque évolution dérapeL'audit
Deux à quatre semaines selon la taille de la base de code. Chaque étape produit un livrable que vous conservez.
L'inventaire complet de ce qui est à votre nom, du dépôt de code aux services tiers, en passant par les noms de domaine. On commence par là, car un blocage sur un compte Apple peut coûter des semaines.
Inventaire des accèsArchitecture réelle, dépendances et leur niveau d'obsolescence, couverture de tests, zones que plus personne ne comprend. C'est ici que l'IA nous fait gagner le plus de temps : lire vite une base inconnue est exactement ce qu'elle sait faire.
Cartographie techniqueFailles connues dans les dépendances, données personnelles mal protégées, secrets laissés dans le code, absence de sauvegarde. On les classe par gravité et par coût de correction.
Liste prioriséeC'est ce qui décide de la suite. Un modèle sain se reprend ; un modèle incohérent condamne souvent à la réécriture, quelle que soit la qualité du reste.
Verdict reprise / réécritureLe plan chiffré
Chaque scénario arrive avec son budget, son délai et ses conditions. Vous comparez les trois chiffres avant de choisir.
On corrige les failles, on remet les dépendances à niveau, on republie une version compatible avec les systèmes actuels. L'application repart sans changer de forme.
Quand · Le code est sain, mais négligé.
On stabilise, puis on rembourse la dette qui bloque réellement : tests sur les parcours critiques, refonte des zones les plus fragiles, documentation. Le produit redevient modifiable.
Quand · Le modèle de données tient, l'architecture a dérivé.
On repart d'une base neuve en conservant ce qui marche : les parcours éprouvés, les données, les apprentissages. Ce n'est jamais notre première recommandation.
Quand · Le modèle de données est incohérent, ou la technologie est abandonnée.
Après la reprise
iOS et Android sortent une version majeure par an. Vos utilisateurs demandent des fonctions, vos concurrents avancent, la réglementation change. Sans entretien, une application repart en dette dans les dix-huit mois, y compris celle que vous venez de reprendre.
C'est le rôle de la tierce maintenance applicative (TMA) : garder votre application à jour, sûre et capable d'évoluer.
Vous réservez chaque mois une capacité exprimée en jours. Ce qui n'est pas consommé se reporte sur le cycle suivant, dans une limite convenue.
À chaque cycle, nous arbitrons ensemble entre correctifs, dette et évolutions. C'est vous qui tranchez, avec notre avis technique posé sur la table.
Vous voyez ce qui a été consommé, sur quoi, et ce qui reste. Rien ne se noie dans un forfait opaque, et la comparaison reste toujours possible.
Vous pouvez internaliser, changer de prestataire ou réduire le volume quand vous le souhaitez. La documentation est tenue à jour précisément pour cela.
Coûts
L'audit est la seule étape que nous chiffrons avant d'avoir vu le code. Tout le reste en découle.
Fourchettes indicatives, août 2026. Voir toutes nos fourchettes de prix →
Questions fréquentes
Les réponses sont directes, y compris quand elles vont contre notre intérêt commercial immédiat.
Oui, c'est une part croissante de notre activité et nous n'y mettons pas de condition de qualité préalable. Nous avons repris des bases très propres et d'autres franchement difficiles. Ce que nous demandons, c'est de commencer par l'audit : nous engager sur un chiffre sans avoir lu le code ne rendrait service à personne.
Deux à quatre semaines selon la taille de la base. Vous recevez un inventaire de ce que vous détenez réellement, une cartographie technique, une liste de risques classés par gravité, et un plan chiffré en trois scénarios. Ce document vous appartient, y compris si vous confiez la suite à quelqu'un d'autre.
C'est plus fréquent qu'on ne le croit, et ce n'est pas toujours bloquant. Il faut d'abord vérifier ce que dit votre contrat : dans la plupart des cas, le code vous appartient et le prestataire est tenu de vous le remettre. Si la récupération échoue, l'audit porte alors sur l'application publiée et sur vos données, et la réécriture devient la voie réaliste.
Non, sauf si c'est réellement le moins cher des trois scénarios. La réécriture est confortable pour un prestataire (un terrain neuf, aucun code d'autrui à comprendre) et coûteuse pour vous. Nous ne la recommandons que lorsque le modèle de données est incohérent ou la technologie abandonnée. Dans les autres cas, reprendre coûte moins et va plus vite.
On la traite par ordre de risque, en plusieurs étapes : les failles de sécurité et les blocages de publication d'abord, la fragilité des parcours critiques ensuite, le confort de développement en dernier. Une reprise peut très bien s'étaler sur plusieurs trimestres, avec une application qui fonctionne à chaque étape.
Non, et nous ne la vendons pas comme telle. Certains clients reprennent la main en interne juste après : c'est un résultat parfaitement acceptable, et c'est même pour cela que nous documentons. La maintenance a du sens quand vous n'avez pas d'équipe technique et que l'application est critique pour votre activité.
Votre application existante
Trente minutes pour comprendre la situation, vérifier ce que vous détenez et estimer l'ampleur de l'audit. Si votre application n'a pas besoin d'être reprise, nous vous le dirons : c'est arrivé plus d'une fois.