Votre POC a prouvé le besoin. Reprenez-en le contrôle : passez en production.

Rétro-spec

Cadrage · forfait

Analyse de l'existant — prototype, code prestataire ou périmètre SaaS —, outillée par mon pipeline agentique : reconstruction de la spécification fonctionnelle et technique, cartographie et identification des zones à risque. Livrable : la spec reconstituée, la cartographie et un plan de reprise comparant les scénarios en coût, risque et délai.

Recodage

Enterprise grade · iso-fonctionnel

Production de l'application complète en qualité entreprise, à fonctionnalités et interface identiques : le métier conserve exactement son outil. Sur un périmètre fermé par la rétro-spec, la phase s'engage au forfait ; sur un périmètre encore ouvert, en régie. Standards complets : specs exécutables, revue, tests automatisés, CI/CD.

Run

Maintenance en abonnement

Une application en production se maintient. Le run est couvert par un abonnement de maintenance, avec le même niveau d'exigence que le recodage. La spécification et la documentation produites vous appartiennent : le système reste réversible et reprenable par un tiers.

Peut-on vibecoder une première version plutôt qu'écrire un cahier des charges ?

Oui, et c'est un usage qui se généralise : pour un manager ou un PO, faire exister une première version avec l'IA est souvent plus rapide et plus précis que rédiger un cahier des charges. Ce prototype sert alors de spécification vivante : il est rétro-spécifié, puis entièrement recodé en qualité production, à fonctionnalités et interface identiques, avec revue, tests automatisés et CI.

La DSI refuse de passer mon application en production, que faire ?

C'est un cas devenu fréquent : un PO ou un manager construit avec l'IA une application qui fonctionne et rend déjà service, et la DSI refuse la mise en production car le code ne tient pas ses standards. L'application existante est alors traitée comme une spécification vivante : elle est rétro-spécifiée, puis entièrement recodée à fonctionnalités et interface identiques, avec les standards attendus en production (revue, tests automatisés, CI). Le métier conserve exactement son outil et la DSI reçoit un code qu'elle peut accepter.

Comment reprendre le contrôle d'un logiciel développé par un prestataire ?

En traitant la solution existante comme la source : le code fait foi. La spécification est reconstruite par rétro-spec, avec une cartographie du système et un plan de reprise. Sur cette base, l'application est recodée en qualité production, à fonctionnalités et interface identiques — et elle vous appartient. La démarche fonctionne même sans documentation et sans le développeur d'origine.

Peut-on remplacer un SaaS devenu trop cher par un outil interne ?

Oui, par internalisation progressive : le SaaS sert de référence fonctionnelle pour le périmètre que vous utilisez réellement. Ce périmètre est rétro-spécifié, puis recodé en interne, et la bascule remplace l'abonnement par un outil qui vous appartient. Le plan de reprise compare coût, risque et délai avant tout engagement.

Qu'est-ce qu'une rétro-spec ?

Une documentation rétroactive : la spécification fonctionnelle et technique est reconstruite en analysant l'existant — prototype, code prestataire ou périmètre SaaS. Le livrable comprend la spec reconstituée, la cartographie et un plan de reprise chiffrable. C'est cette étape qui ferme le périmètre et rend la suite forfaitisable.

Qui assure la maintenance ensuite ?

Le run est couvert par un abonnement de maintenance, avec le même niveau d'exigence que le recodage lui-même : revue, tests automatisés, CI. L'objectif reste la réversibilité : la spécification et la documentation produites vous appartiennent, et le système reste reprenable par un tiers.