Faire évoluer une application web déjà en production : quelle agence choisir
Pour faire évoluer une application web déjà en ligne, choisissez une agence qui part de votre code sans imposer de réécriture, l'audite avant de promettre, et facture d'une façon qui suit vos priorités. Les six critères, le bon modèle et les signaux d'alerte.
Sommaire
Pour faire évoluer une application web déjà en production, choisissez une agence qui accepte de partir de votre code existant sans imposer de réécriture, qui l'audite avant de promettre quoi que ce soit, et dont le mode de facturation suit un produit qui change : abonnement ou forfait cadré selon que votre périmètre est ouvert ou fermé. Vérifiez aussi que le code et les accès vous appartiennent à chaque livraison.
Faire évoluer une application existante, ce n'est pas la construire
Votre application tourne. Des clients s'en servent tous les jours. Le prestataire qui l'a construite est parti, ne suit plus, ou transforme chaque demande en avenant. Vous cherchez la suite, et les agences que vous rencontrez vous parlent comme si vous partiez de zéro.
Faire évoluer une application en production n'est pas le même travail que la construire. Quatre choses changent.
- Un code écrit par d'autres. L'agence doit le lire et le comprendre avant de le modifier. Pas le juger à son goût.
- Des utilisateurs actifs. Chaque livraison touche des gens qui travaillent avec l'outil. Une régression se voit le jour même.
- De la dette technique. Les raccourcis d'hier ralentissent chaque évolution d'aujourd'hui. Elle se rembourse par petites étapes, rarement d'un coup.
- Des accès dispersés. Dépôt, hébergement, domaine, comptes tiers : ils sont souvent à plusieurs noms, parfois à celui de l'ancien prestataire.
Une agence taillée pour les projets neufs voit tout cela comme un obstacle. Celle qu'il vous faut le voit comme son point de départ.
Pour savoir ce qui, dans votre code, se répare, se rembourse ou se remplace, lisez dette technique : refondre ou faire évoluer.
Les 6 critères pour choisir l'agence
Toutes les agences disent qu'elles savent reprendre un existant. Ces six critères séparent celles qui le font de celles qui le promettent. Pour chacun, une question à poser en rendez-vous : écoutez moins les mots que la précision de la réponse.
Elle reprend l'existant sans imposer de refonte
Une agence qui propose de tout refaire travaille dans son code à elle, pas dans le vôtre. C'est plus confortable pour elle, rarement pour vous : vous payez le logiciel une seconde fois, pendant que l'ancien continue de demander des corrections. Refondre un module peut se justifier, plus tard, avec des faits.
À demander : « Que faites-vous si mon code ne vous plaît pas ? »
Elle regarde le dépôt et les accès avant de s'engager
Un prix ou un délai donné sans avoir ouvert le code est une estimation à l'aveugle. La stack, l'état des dépendances et la façon de déployer se lisent vite, et changent tout le reste. Une agence sérieuse vous dit ce qu'elle reprend, et ce qu'elle ne reprend pas.
À demander : « Quand regardez-vous mon code : avant ou après la signature ? »
Elle livre sans casser la production
Vos utilisateurs ne doivent pas servir de testeurs. Demandez comment une modification arrive en ligne : un environnement de test où vous validez avant, une relecture du code par une autre personne, des livraisons par petites étapes. Une grosse livraison tous les deux mois concentre le risque sur un seul jour.
À demander : « Comment une modification arrive-t-elle en production, et qui la vérifie avant ? »
Elle dit qui fait le travail
Des ingénieurs en interne, des freelances en sous-traitance, une IA qui génère le code : les trois existent, parfois dans la même agence. L'IA accélère vraiment le travail. Mais un code livré sans relecture humaine devient vite une nouvelle dette. Ce qui compte : qui valide chaque livraison, et si cette personne fait partie de l'agence.
À demander : « Qui écrit le code, qui le relit, et l'IA livre-t-elle seule ? »
Le code et les accès restent à vous
Le code, les maquettes et la documentation doivent vous être cédés par écrit, à chaque livraison payée plutôt qu'en fin de projet. Le dépôt, l'hébergement et le domaine doivent être à votre nom. Et la sortie se prévoit à l'entrée : ce que vous récupérez, sous quel délai, à quel prix.
À demander : « Si j'arrête demain, qu'est-ce que je récupère ? »
Sa facturation suit un produit qui change
Sur une application en production, les priorités bougent chaque mois : un client demande une intégration, un bug passe devant, une idée tombe. Un modèle qui fait de chaque changement un avenant vous fait payer la négociation autant que le travail. Le bon modèle dépend de votre périmètre : la section suivante tranche.
À demander : « Que se passe-t-il quand je change une priorité en cours de route ? »
La clause à exiger, droit par droit, est détaillée dans à qui appartient le code de votre application.
Forfait, régie, TMA ou abonnement : quel modèle pour une application qui évolue
Les agences ne se distinguent pas que par leurs compétences. Elles se distinguent par leur façon de facturer, et c'est elle qui décide de ce qui se passe quand votre roadmap bouge. Quatre modèles, côte à côte.
| Modèle | Comment on paie | Quand une priorité change | Pour qui | Le risque principal |
|---|---|---|---|---|
| Agence au forfait | Un devis par projet, puis un avenant par ajout | Un avenant : nouveau cadrage, nouveau chiffrage, nouveau délai | Un périmètre fermé : refonte cadrée, date imposée | Payer en avenants une application qui change chaque mois |
| Régie ou freelance | Des jours, au temps passé | Elle change sans contrat, mais c'est vous qui pilotez | Une équipe qui a déjà quelqu'un pour cadrer, relire et valider | Payer des jours plutôt que des livraisons, et dépendre d'une disponibilité |
| TMA ou contrat de maintenance | Un forfait ou un volume d'heures, souvent à l'année | Le contrat couvre surtout la correction ; une évolution passe souvent par un devis à part | Une application stable, qui doit surtout tourner | Un produit maintenu, mais qui n'avance plus |
| Abonnement de développement | Un prix fixe par mois, sans engagement | Vous réordonnez votre file, sans rien renégocier | Une application en production dont les priorités bougent | Une demande active à la fois par slot : pas fait pour tenir une date imposée |
Chez Figue, les deux modèles existent. L'abonnement Figue Unlimited coûte 1 990 € HT par mois et par slot, sans engagement : la page développement illimité détaille ce qu'il comprend.
Nos forfaits projet démarrent à 990 € HT, avec un prix fixé avant démarrage.
Pour les ordres de grandeur des autres modèles, salarié, freelance ou agence, voyez combien coûte un développeur.
Les signaux d'alerte en rendez-vous
Ces signaux n'accusent personne. Ils montrent une façon de travailler qui ne convient pas à une application en production. Un seul ne disqualifie pas une agence. Plusieurs ensemble, si.
Une refonte proposée avant d'avoir lu le code
Si la première recommandation arrive avant l'ouverture du dépôt, elle repose sur une habitude, pas sur votre application. Une refonte se décide avec des faits : quels modules, quels incidents, quel temps perdu.
Un délai garanti sans audit
Personne ne peut promettre une date sur un code qu'il n'a pas lu, avec des accès qu'il n'a pas reçus. Une date ferme donnée au premier rendez-vous sera tenue en rognant ailleurs, ou ne sera pas tenue.
Un code qui reste chez l'agence
Un dépôt au nom de l'agence, un hébergement sur son compte, une cession prévue en fin de projet : le jour où vous voudrez partir, vous partirez sans votre application.
Chaque changement transformé en avenant
Sur une application qui vit, le changement est la norme. Si chaque ajustement relance un cadrage, un chiffrage et un délai, la mécanique du contrat finit par coûter plus que le travail.
Ces signaux valent quel que soit le modèle de l'agence. Pour comparer point par point une agence au devis et un abonnement, voyez Figue vs agence.
Ce qu'il faut préparer avant de changer d'agence
Changer d'agence se prépare avant de la choisir. Plus vous arrivez avec vos accès et votre liste, plus le premier rendez-vous est utile : l'agence regarde votre application, pas un résumé.
Si une partie de ces accès est encore chez votre prestataire actuel, demandez-les par écrit maintenant, pendant que la relation est simple.
La liste complète, secrets et procédure de déploiement compris, est dans notre guide pour reprendre le code d'un prestataire.
Comment Figue reprend une application en production
La plupart de nos clients arrivent avec un produit déjà en ligne : web, mobile, SaaS, outil métier. Voici comment se passe la reprise, sans rien promettre de plus.
Il n'y a pas de délai garanti. La durée d'une demande dépend de sa complexité, des accès nécessaires et des vérifications à faire. On clarifie le périmètre et les étapes avec vous avant de démarrer.
Le premier pas est un appel découverte offert de 45 minutes, en visio, sans engagement. Montrez-nous votre application : on vous dit si on la reprend, et par quelle demande commencer.
