Caroline B.
Cheffe de marques
Refonte et reprise de projet
Un logiciel qui vieillit, un développement interrompu, un prestataire parti : nous commençons par un audit technique qui chiffre le code en place, et ce chiffrage ouvre le choix entre refonte, reprise et modernisation.
15 ans
d'expérience
250+
missions réalisées
+30
projets en activité
100%
sur-mesure
Ils nous font confiance
LE CONSTAT
Ce qui retarde la refonte d'un outil qui fonctionne encore
Vos réunions de direction traitent ce qui bloque. Un logiciel qui fonctionne encore y échappe : il sort les documents, il traite les dossiers, vos équipes s’en servent tous les jours. Une situation confortable, et c’est ce qui la fait durer.
Elle dure jusqu’au jour où vous demandez une évolution. Le chiffre qui revient vous paraît élevé pour la modification demandée. Savoir s’il tient à la difficulté du travail ou à l’état de ce qu’il y a dessous demande une lecture technique que vous n’avez pas commandée. Vous reportez, puis vous reportez encore, et votre logiciel finit par appliquer des règles que votre entreprise a cessé de suivre.
D’autres questions restent ouvertes en arrière-plan, et elles reviennent toutes le même jour. Qui détient l’hébergement, le nom de domaine, les comptes chez les services extérieurs que votre application appelle : des gens différents les ont ouverts pendant le projet, parfois au nom de la société qui développait. Tant que la relation dure, personne ne pose la question. Le jour où elle s’arrête, elle passe devant toutes les autres.
Vient ensuite la compétence. Celui qui a écrit l’application est parti, ou la société qui l’a livrée a cessé de répondre aux demandes d’évolution. Le logiciel continue de tourner, seul, et l’explication de sa construction s’en va avec les gens qui l’avaient.
Un développement interrompu pose le même problème sous une autre forme. Vous avez payé, une partie fonctionne, une autre attend, et l’écart entre les deux se chiffre par quelqu’un qui ouvre le code.
Ces situations mènent à des chantiers différents, et il leur manque la même information : ce que le logiciel en place est capable d’absorber, et à quel coût. Un dirigeant sait dire ce que son activité demande. L’état du logiciel qui la fait tourner relève d’une lecture technique, et cette lecture se commande. C’est le travail d’un audit technique, celui des quatre chantiers qui donne le chiffre.
Vous vous reconnaissez ?
Ce qui amène une entreprise à reprendre un développement existant
Vous reconnaîtrez votre situation sans ouvrir le code.
Votre outil tourne et son auteur est parti
Il fait son travail tous les jours. La question de savoir qui saurait le modifier reste ouverte depuis des mois.
Le projet s'est arrêté avant sa mise en service
Vous avez payé une partie du développement, les écrans existent, et ils attendent tous une mise en service.
Chaque devis d'évolution dépasse ce que l'évolution rapporte
Vous avez fini par cesser de demander. Vos équipes s'arrangent avec ce que l'outil sait faire.
Vos accès portent le nom d'une autre société
Une société avec laquelle vous avez cessé de travailler détient encore l'hébergement, le nom de domaine ou le serveur qui garde le code.
Un rachat vous a laissé un outil sans mode d'emploi
Il porte l'activité rachetée, vos équipes l'utilisent, et ses règles de calcul restent à reconstituer.
Vous arbitrez cet investissement cette année
Garder, reprendre ou remplacer : la décision tombe cette année, et vous cherchez un avis extérieur au dossier.
Dans ces six cas, il manque la même chose : le relevé technique que le constat qui précède vient de décrire. C’est le point d’entrée commun aux quatre chantiers que nous menons sur un logiciel déjà en service.
NOS SERVICES
Ce que recouvre une refonte et reprise de projet
Une même situation appelle parfois deux de ces chantiers, menés l'un après l'autre.
Audit technique
Nous lisons le code et les données, nous relevons l'hébergement et les accès, puis nous rendons un état des lieux chiffré. Cet audit technique se facture seul et son résultat vous appartient.
Refonte d'application ou de plateforme
Votre activité a changé, l'application applique encore les règles d'origine. Une refonte d'application ou de plateforme les redécide avec vous, fonction par fonction.
Reprise de projet existant
Un développement mené ailleurs vous revient, terminé ou non. La reprise de projet existant commence par récupérer les accès et établir ce que l'équipe précédente a livré.
Modernisation d'un outil vieillissant
Vos écrans et vos règles conviennent, la base technique en dessous suit mal. La modernisation d'un outil vieillissant la change sans toucher aux gestes de vos équipes.
Nos dernières réalisations
Toutes nos réalisations 4,8
CE QU'ILS EN DISENT
Nous avons aidé des dizaines de clients dans leur transformation digitale
-
Equipe très à l'écoute, dynamique, réactive, de très bons conseils, très pro, à la fois très techniques mais qui sait aussi se mettre à la place de personnes non averties.
-
Laurence V.
Directrice Marketing
Nous ne pouvons que nous féliciter de notre choix d'agence web : une équipe sympathique, à l'écoute, professionnelle, rigoureuse, technique... présente tout en respectant nos contraintes.
-
Mirela O.
Reponsable Marketing
À l'écoute, disponibles et très créatifs, ils comprennent rapidement les besoins de leurs clients et leurs conseils sont opportuns.
-
Tiffany V.
Responsable Communication
Bonne compréhension des enjeux et attentes, couplée à de la créativité : tout est fluide. J'apprécie leur accompagnement, leur prise en charge et la disponibilité des équipes.
Faites auditer votre outil avant de décider
Décrivez-nous votre outil et vos accès, nous vous rendons un audit chiffré, facturé seul, sans engagement pour la suite.
Le déroulé d'une refonte ou d'une reprise, du relevé à la passation
-
Nous établissons qui garde le code, qui héberge quoi, qui détient chaque compte et quels services extérieurs votre logiciel appelle. Vous ressortez avec la liste de ce que vous détenez et de ce qui manque encore. Cette liste précède tout chiffrage.
-
Nous ouvrons l'application et sa base. Nous en tirons les fonctions que vos équipes utilisent, les règles de calcul qu'elle applique, l'état des données accumulées et le travail que chaque bloc représente à reprendre. Si vous n'avez commandé que l'audit technique, ce document en est le livrable final et le chantier s'arrête ici. Pour une refonte, une reprise ou une modernisation, il ouvre les étapes suivantes.
-
Une séance avec vous, le document d'audit ouvert. Nous chiffrons devant vous ce que représente chaque partie de l'outil, et vous fixez celles que vous engagez cette année. Le périmètre du chantier sort de cette séance, et son chiffrage avec lui.
-
Nous livrons un ensemble cohérent à la fois, mis en service dès qu'il tient. Quand un ancien outil tourne encore, il reste ouvert derrière et vos équipes basculent bloc par bloc, au rythme des mises en service ; quand rien n'a jamais été mis en service, chaque lot livré entre directement en usage, sans bascule à orchestrer.
-
Nous vous remettons les accès à votre nom, le dossier qui décrit la construction de l'application et sa mise en ligne, ainsi que la pleine propriété du code : elle vous revient dès la livraison, sans clause qui nous en réserve l'usage. Vos demandes d'évolution reprennent ensuite au rythme de votre activité. Ce suivi entre dans le contrat de maintenance et d'évolution, distinct du forfait initial.
Reprendre un outil existant : ce que les dirigeants nous demandent
Oui. Deux choses suffisent pour commencer : vos accès, et une description de ce que vos équipes font avec l’outil au quotidien. Le reste se lit dans le code et dans la base, c’est notre travail. Ce que vous savez déjà nous est utile ailleurs : quelles opérations reviennent tous les jours, lesquelles posent problème, quelle règle de calcul vous tenez à conserver telle quelle. Ces éléments-là ne s’obtiennent qu’auprès de vous.
.Non. Il se facture seul et son résultat vous appartient, sans clause qui vous lie à la suite. Ce document circule ensuite comme vous l’entendez, y compris chez une autre équipe que vous voudriez mettre en concurrence sur le chantier. Nous tenons à ce découpage parce qu’un audit dont la conclusion serait acquise d’avance ne servirait ni votre décision ni notre crédibilité. Il sert autant à justifier un investissement qu’à démontrer qu’il peut attendre.
.Par celui qui bloque une décision que vous voulez prendre cette année. Nous relevons l’ensemble des outils concernés, ce qui prend peu de temps, puis nous regardons deux choses pour chacun : ce que son arrêt coûterait à votre activité, et ce que coûterait dessus la première évolution que vous attendez. Le classement sort de là. Traiter le parc en une seule fois allonge le calendrier et repousse le premier bénéfice, alors que le premier outil remis en état finance la suite.
.Elle continue. Le point à régler tient aux données saisies pendant la transition, quand deux outils tournent en parallèle. Nous décidons avec vous, avant le premier développement, lequel des deux fait foi sur chaque type de dossier et comment les deux se rejoignent à la fin. Ce point se tranche tôt : plus il attend, plus la remise en ordre coûte cher.
.Cela dépend du chantier. Une modernisation d’un outil vieillissant laisse vos équipes travailler comme avant, seule la base technique change. Une refonte d’application ou de plateforme redécide les fonctions, donc les écrans bougent, et nous prenons pour point de départ ce que vos utilisateurs font aujourd’hui. Dans les deux cas, ceux qui se servent de l’outil manipulent la nouvelle version avant sa mise en service. Un écran qui les gêne se corrige à ce stade, avant que le développement ne s’appuie dessus.
.Nous les recensons dans l’audit, avant tout engagement, et chacun rejoint la liste des blocs à arbitrer avec son coût de remise en état. Vous décidez lesquels entrent dans le chantier et lesquels attendent. Ce qui compte, à ce moment, est de séparer ce qui était déjà là de ce que nous introduisons : la comparaison sur vos propres dossiers, avant et après chaque lot, établit cette frontière.
.Le relevé du premier chantier sert justement à fermer cette fenêtre au plus vite. Chaque accès identifié au nom d’un tiers sorti du dossier, hébergement, nom de domaine, compte de service, est transféré ou renouvelé à votre nom l’un après l’autre, et jusqu’à ce transfert, ce tiers ne conserve aucun moyen d’intervenir seul sur le code ou les données en production. Pendant la période où l’ancien et le nouveau système tournent en parallèle, les mêmes règles d’accès nominatif s’appliquent aux deux, et les données saisies dans l’un ou l’autre restent sous votre seul contrôle jusqu’à ce que la bascule les réunisse.
. POUR ALLER PLUS LOIN
Reprise ou refonte : les points qu'un dirigeant tranche avant d'engager
La règle qui départage reprendre et refaire
L’ancienneté d’une application pèse peu dans notre jugement. Un outil ancien, peu modifié depuis sa livraison et écrit par une équipe qui tenait sa ligne, se reprend mieux qu’une application récente qu’une succession d’intervenants a corrigée dans l’urgence.
La règle que nous appliquons tient en une opération. Nous prenons une évolution réelle, celle que vous avez inscrite au budget de l’année, et nous la chiffrons sur le code en place. Ce chiffre se compare ensuite à deux choses : ce que la même évolution coûterait sur une base neuve, et ce qu’elle doit vous rapporter. Quand le premier montant s’approche du deuxième, reprendre le code existant cesse de se justifier, quel que soit son état apparent.
Cette opération sert au-delà de la décision du jour. Elle donne un ordre de grandeur du coût de vos évolutions à venir, celles que vous n’avez pas encore formulées. Vous savez alors ce qu’une demande de vos équipes coûtera avant de la leur promettre.
Refonte de site et refonte d’application, deux chantiers différents
Le mot refonte sert pour deux travaux distincts, et le budget s’en ressent dès la première discussion.
Une refonte de site porte sur des pages, des contenus et des adresses qui rapportent des demandes. L’enjeu principal est de conserver la place acquise dans les résultats de recherche pendant que la forme change. Une refonte de site relève de notre branche Sites internet, avec ses propres arbitrages.
Une refonte d’application touche des règles, des données et des utilisateurs internes. Elle se juge sur un point : un dossier traité par la nouvelle version donne le même résultat que par l’ancienne, sauf là où vous avez décidé le contraire. L’enjeu se déplace donc de la visibilité vers la continuité du travail quotidien.
Certaines entreprises portent les deux en même temps, avec un site public relié à un outil interne. Les deux chantiers se mènent alors séparément, dans cet ordre : l’outil qui produit l’information d’abord, le site qui l’affiche ensuite.
Remplacer par un produit du marché plutôt que reprendre
Devant un outil vieillissant, remplacer par un produit du marché reste une option sérieuse, et nous la regardons avec vous. Un produit qui couvre votre besoin coûte moins qu’un développement et il arrive plus vite.
Le passage se joue sur vos calculs. Ce que votre outil actuel sait faire de vos règles de tarification, de commission ou de prorata, un produit standard le reprend jusqu’à un certain point, puis il vous demande de simplifier. Listez donc les calculs que vous appliquez et que vous refusez de changer, et présentez cette liste au produit que vous regardez avant toute autre comparaison. Ce qu’il accepte départage les deux voies mieux qu’un tableau de fonctionnalités.
La seconde condition tient à votre historique. Des années de dossiers, de pièces et de justificatifs doivent rester consultables après le passage, sous une forme que vos équipes savent retrouver. Un produit qui impose son propre modèle reprend une partie de cette matière et laisse le reste dehors. Ce point se vérifie avant la signature, avec un échantillon réel de vos données plutôt qu’avec une démonstration.
Reprendre un développement sans son auteur
Un code écrit par quelqu’un d’autre se reprend, et trois points en fixent la difficulté. La qualité de l’écriture pèse moins qu’eux.
Le premier est la mise en ligne. Savoir installer l’application ailleurs, la faire tourner sur une copie et y publier une modification conditionne tout le reste. Quand quelqu’un a écrit cette procédure, nous partons de là. Quand une seule personne la connaissait et qu’elle est partie, la reconstituer devient la première tâche du chantier de reprise de projet existant, chiffrée dans son périmètre plutôt que comme un poste séparé.
Le deuxième est l’écart entre ce que le code fait et ce que vos équipes croient qu’il fait. Il se mesure dossier par dossier, et il réserve des surprises dans les deux sens : une règle appliquée que personne ne réclamait, une autre que tout le monde croyait active.
Le troisième est la base de données. Elle garde la trace de tout ce que l’application a traité et elle survit aux réécritures. Un modèle cohérent compense des faiblesses ailleurs dans le code, un modèle incohérent finit par les imposer à ce que vous reconstruisez. Ces trois points ouvrent une reprise de projet existant, avant même de parler de ce que le nouvel outil devra faire de plus.
Le dossier que nous laissons derrière nous
Prendre la suite d’une autre équipe fait partie de notre travail. Cette place donne une idée précise de ce qui manque au moment d’une passation, et nous produisons donc le dossier que nous aurions voulu trouver.
Il contient de quoi installer l’application ailleurs et la remettre en ligne, la description des règles de calcul qu’elle applique et l’origine de chacune, la liste des services extérieurs qu’elle appelle avec le compte utilisé, et la trace des décisions du chantier — les mêmes accès que nous vous remettons à votre nom dès la passation.
Ce dossier rend une équipe extérieure capable de prendre notre suite. Un prestataire qui garde pour lui les moyens d’intervenir gagne une sécurité commerciale et vous laisse le risque. Nous remettons ce dossier dès le premier chantier. Le jour où vous décidez de confier la suite à quelqu’un d’autre, il est déjà chez vous.
