Les évolutions prennent de plus en plus de temps
Chaque ajout casse quelque chose ailleurs. L'équipe passe plus de temps à corriger qu'à construire.
Mode d'intervention
Audit et reprise d'application
que personne n’ose
plus faire évoluer.
Un produit ralenti, fragile, difficile à faire évoluer ou laissé sans équipe. Nous diagnostiquons l'existant, priorisons les risques et reprenons le produit quand c'est la bonne décision.
diagnosticDIAGNOSTIC
Gestion des erreurs
Les échecs de paiement remontent sans message exploitable : l’utilisateur reste bloqué et l’incident n’est pas tracé.
ACTION RECOMMANDÉE
Isoler le parcours de paiement, ajouter un message d’échec et une trace côté serveur.
Dépendances
Versions figées depuis plusieurs cycles, dont deux avec des correctifs de sécurité publiés.
Tests
Les parcours critiques ne sont pas couverts : aucune alerte avant la mise en production.
PRIORITÉ À TRAITER EN PREMIERCODE · EXPLOITATION · TESTS
Situations
Ce qui déclenche un diagnostic.
Le produit est instable en production
Plantages, régressions, incidents difficiles à reproduire, absence de supervision utilisable.
Le prestataire a abandonné l'application
Il ne répond plus ou a cessé son activité. Plus personne ne connaît la base de code, la documentation est absente ou périmée, et les accès sont incomplets.
Une décision de refonte est sur la table
Quelqu'un propose de tout réécrire. Vous voulez savoir si c'est justifié avant d'engager le budget.
Contenu du diagnostic
Ce que nous pouvons prendre en charge dans vos équipes.
Un diagnostic utile demande l'accès en lecture au dépôt, aux environnements et aux outils de suivi, ainsi qu'un échange avec les personnes qui connaissent le produit.
Architecture et code
Structure, couplages, dépendances, versions et écarts avec l'état de l'art des plateformes visées.
Qualité et tests
Couverture réelle, fiabilité de la chaîne d'intégration, capacité à livrer sans régression.
Exploitation et sécurité
Déploiement, supervision, gestion des secrets, traitement des données personnelles et dépendances vulnérables.
Performance et coûts
Temps de réponse, consommation d'infrastructure et points de coût évitables.
Parcours utilisateurs
Là où les parcours décrochent : abandons signalés, écrans inutilisables, incohérences d'interface accumulées au fil des versions.
Livrables du diagnostic
Cartographie de l'existant, risques priorisés, options argumentées et estimation du prochain lot.
Méthode
Ce qui se passe après le diagnostic.
- 01
Trois issues possibles
Conserver et corriger, refondre une partie, ou engager une réécriture argumentée. La réécriture n'est pas présentée comme la réponse par défaut : elle recommence aussi les décisions déjà validées.
- 02
Stabiliser les parcours critiques
Les parcours qui portent l'usage et le revenu sont isolés et sécurisés en premier, par des tests et une supervision exploitable. La dette conservée ailleurs est documentée, pas dissimulée.
- 03
Migrer progressivement
Quand une migration est retenue, elle se mène par vagues sur un produit qui reste en production, plutôt que par un basculement unique.
- 04
Reprendre la maintenance
Si la reprise est décidée, la maintenance et les évolutions se contractualisent ensuite, avec un périmètre et un rythme définis.
Responsabilités
Ce qui revient à chacun.
Répartition courante des responsabilités, arrêtée mission par mission dans le contrat.
| Sujet | Chez vous | Chez Black Tide |
|---|---|---|
| Accès | Vous ouvrez les accès en lecture | Nous travaillons dans le périmètre ouvert, sans copie hors de votre organisation |
| Périmètre du diagnostic | Vous fixez ce qui doit être regardé en priorité | Nous signalons ce que ce périmètre laisse de côté |
| Décision | Vous choisissez l'option retenue | Nous documentons les conséquences de chaque option |
| Stabilisation | Vous arbitrez ce qui est corrigé en premier | Nous sécurisons les parcours critiques d'abord |
| Suite | Vous décidez qui reprend le produit | Nous préparons la reprise, par nous ou par une autre équipe |
Preuve
Un audit sous contrainte de date, une reprise en production.
Parkto
Audit et stabilisation en quatre semaines, avec une date de lancement fixée à l'avance : cartographie de la dette, isolement des trois parcours critiques, puis transmission avec un plan de rattrapage. Ce calendrier était celui de cette mission, pas un délai standard.
Lire le cas ParktoBlisterr
Reprise en cours sur un produit en production : migration applicative par vagues et migration du backend table par table, sans interruption de service.
Lire le cas BlisterrUne reprise se mesure sur ce qui est stabilisé et documenté, pas sur une promesse de remise à neuf.
Cadre commercial
Comment se cadre un diagnostic.
Durée et périmètre
La durée dépend de la taille de la base de code et des accès disponibles. Elle est fixée avec vous avant de commencer, avec la liste de ce qui sera examiné.
Le diagnostic est une prestation
Il est facturé, parce qu'il demande de lire réellement le code et l'exploitation. Nous ne proposons pas d'audit gratuit qui servirait de démarchage.
Reprise de maintenance
Si la reprise est décidée, la maintenance et les évolutions se contractualisent ensuite, avec un périmètre et un rythme définis.
Transmission possible
Les livrables sont écrits pour qu'une autre équipe puisse reprendre. La reprise par nos soins n'est pas la condition du diagnostic.
Questions utiles
Ce qu'on nous demande avant un diagnostic.
Faut-il forcément tout réécrire ?
Rarement. Une réécriture complète recommence aussi les décisions déjà validées et les cas limites déjà traités. Nous la proposons quand le coût de maintien dépasse le coût de reconstruction, avec les éléments qui le montrent.
Pouvez-vous auditer sans accès au code ?
Nous pouvons examiner le contexte et les symptômes, mais un diagnostic technique du code exige un accès au dépôt. Les limites du diagnostic sont explicitées.
Notre prestataire ne répond plus : comment récupérer le code et les accès ?
Commencez par dresser l'inventaire de ce qui est à votre nom : dépôt de code, comptes App Store Connect et Google Play Console, nom de domaine, hébergement et services tiers. Nous vous aidons à l'établir et à demander les transferts ; le diagnostic porte ensuite sur ce qui est récupéré.
Les comptes App Store et Google Play sont au nom de l'ancien prestataire : est-ce bloquant ?
Non, mais c'est à régler avant toute nouvelle publication. Apple et Google prévoient tous deux une procédure de transfert d'application entre comptes développeur, qui conserve la fiche, les avis et les utilisateurs existants. Nous la préparons avec vous.
Que se passe-t-il pendant la stabilisation ?
Nous isolons les parcours critiques, corrigeons les problèmes prioritaires et mettons en place les tests et la supervision adaptés. Les évolutions sont coordonnées avec votre équipe.
Reprenez-vous la maintenance à la suite ?
Oui, si cela correspond à votre besoin. Le périmètre de maintenance et les modalités de suivi font l’objet d’un accord distinct.
Prochaine étape
Préparons un diagnostic.
Décrivez les symptômes, les accès disponibles et l'échéance qui vous contraint. Nous vous disons ce qu'un diagnostic peut établir, et à quelles conditions.