Le portail fonctionne pendant la démonstration, mais personne ne sait installer la version présentée sur un environnement neuf. Les derniers écrans sont dessinés, les échanges avec l’ERP restent simulés et la date d’ouverture a déjà changé. Ce retard prolonge les doubles saisies et les corrections manuelles des équipes qui attendaient le nouvel outil. Avant de confier la suite à une nouvelle équipe, il faut savoir si le projet peut produire un premier service utile, avec quels travaux et quelles limites.
Un développement inachevé pose une question différente de la maintenance d’une application en production. Il manque parfois des fonctions ; il manque aussi les moyens de les recevoir : données représentatives, règles métier tranchées, environnement exploitable, tests, procédures et responsables de validation. Une liste de tickets ne raconte pas à elle seule ce qui peut être livré.
Le bon arbitrage consiste à partir du reste à accomplir et de la valeur du premier usage. Le budget déjà consommé explique la situation, mais il ne démontre pas qu’une finition sera moins risquée qu’un recadrage. La priorité consiste à identifier un parcours complet, à vérifier ce qui le soutient réellement et à comparer les trajectoires sur cette même base.
Notre offre de reprise d’application web et de code existant commence par cette qualification avec les métiers et la DSI. Dans une démarche de développement web sur mesure, Dawap rapproche le produit attendu, le code disponible et les conditions de livraison avant de proposer un engagement de réalisation.
Reconnaître un projet inachevé et poser la décision attendue
Le projet concerné n’a pas encore atteint le premier usage attendu, ou seule une partie du service est effectivement ouverte. Un prototype, un portail accessible à quelques testeurs et un logiciel exploité par un établissement ne présentent pas les mêmes obligations. Commencez par nommer les utilisateurs déjà exposés et les opérations qui dépendent réellement du système.
La mission cherche à décider si un périmètre peut être terminé, si une tranche doit être redéfinie ou si certains travaux doivent être abandonnés. Une application déjà utilisée, dont le prestataire change, demande plutôt une passation et une montée en autonomie sur le legacy. Lorsque les deux situations coexistent, séparez la continuité du service ouvert et la relance de ce qui reste à construire.
Un incident actif passe avant l’étude de trajectoire. Les opérations de confinement sont prises en charge par les personnes autorisées, avec une trace des modifications. L’équipe chargée de comprendre le projet doit savoir quel état elle observe ; sinon, elle risque d’attribuer au code initial une difficulté créée pendant l’intervention.
Rassembler les éléments qui rendent l’évaluation possible
Demandez un inventaire des dépôts, branches, versions montrées, dépendances, environnements, comptes, données d’essai, documents fonctionnels et anomalies connues. Pour chaque élément, relevez son détenteur, son emplacement et la dernière version utilisable. Une pièce absente reçoit une demande précise et un interlocuteur, au lieu de disparaître dans une réserve générale.
Les droits de consultation, de modification et d’exploitation sont clarifiés dans le cadre du projet. Une bibliothèque privée, une licence ou un service tiers peut exiger un accès ou un accord particulier. Les questions contractuelles sont traitées avec les interlocuteurs compétents ; disposer d’une archive ne permet pas de présumer tous les droits nécessaires à sa reprise.
Le premier signal faible est la discordance entre la démonstration et les sources : une fonctionnalité existe sur le poste d’une personne, mais aucune version identifiable ne la contient. Le second est une dépendance essentielle administrée depuis un compte auquel le client n’a pas accès. Ces écarts doivent être résolus ou intégrés au planning avant de promettre une livraison.
Conservez une copie de référence et les résultats de l’inventaire. Les secrets passent par un canal sécurisé convenu avec la DSI ; les données de test sont autorisées et adaptées à la confidentialité du projet. Une collecte exhaustive de données réelles n’est pas une condition normale pour comprendre un parcours.
Définir le premier usage complet avec les équipes métier
Remplacez « terminer le portail » par un résultat observable. Par exemple : un acheteur autorisé saisit une demande, un responsable la valide, le système destinataire la reçoit et l’utilisateur retrouve son état. Chaque étape précise l’acteur, la règle, la donnée attendue et la personne qui accepte le résultat.
Les maquettes et les spécifications servent de sources, mais les utilisateurs doivent confirmer les décisions encore actuelles. Une règle peut avoir changé pendant le développement ; une fonction prévue peut avoir perdu sa valeur. L’audit distingue une exigence toujours nécessaire, une proposition devenue obsolète et une question qui n’a jamais été tranchée.
Préparez des cas représentatifs : une demande recevable, une demande refusée, une autorisation insuffisante et une réponse externe retardée. Le métier explique ce qui doit alors se passer. Cette discussion révèle souvent davantage de travail restant qu’un décompte des écrans, parce qu’elle fait apparaître validations, exceptions et responsabilités.
Reproduire une version sans dépendre du poste du développeur
Une équipe autorisée doit pouvoir retrouver les sources, installer les dépendances, configurer un environnement isolé et lancer une version identifiée. Les étapes exécutées, les erreurs et les interventions manuelles sont conservées. Un démarrage réussi après plusieurs corrections non tracées ne prouve pas encore que la version pourra être reconstruite.
Examinez les configurations, les migrations de base, les fichiers nécessaires et les traitements annexes. Un écran peut fonctionner alors que le worker documentaire n’a jamais été installé. Une base copiée depuis une démonstration peut masquer une migration manquante. Le résultat attendu est un état reproductible, avec les limites qui restent à lever.
La chaîne CI/CD doit produire un livrable identifiable et des contrôles adaptés au lot. Sa traçabilité relie les sources d’entrée, les dépendances résolues, les résultats des tests et la version de sortie. Les artefacts de jobs GitLab permettent notamment de conserver des sorties de construction ou de test selon leur configuration et leur durée de rétention. L’existence d’un pipeline vert ne suffit pas : vérifiez les contrôles exécutés et la version réellement installée.
Les essais restent séparés de la production et des services réels. Si une interface de test n’est pas disponible, la simulation est explicitement nommée. Elle permet de développer une partie du parcours ; elle ne démontre pas encore la compatibilité avec le système du client.
Distinguer ce qui est reçu, défectueux, incomplet ou non vérifié
Établissez une matrice par capacité métier, plutôt qu’un pourcentage global d’avancement. Une fonctionnalité peut être présente mais non testée, partiellement raccordée ou incapable de gérer une exception. Ces situations appellent des travaux différents et ne devraient pas porter la même étiquette « terminé ».
| Capacité | État observé dans le scénario | Preuve encore nécessaire |
|---|---|---|
| Saisie d’une demande | Disponible sur le jeu de démonstration. | Cas accepté, refusé et contrôle des droits sur une version installée. |
| Validation métier | Écran présent ; règle d’arbitrage non décidée. | Décision du responsable métier puis tests des transitions. |
| Transmission ERP | Échange simulé ; interface réelle non essayée. | Essai autorisé avec le responsable ERP et rapprochement du résultat. |
| Installation et exploitation | Démarrage manuel ; procédure partielle. | Construction reproductible, configuration et réception du déploiement. |
Chaque écart indique la version, le scénario, le résultat, son impact et l’interlocuteur qui peut lever la dépendance. Les preuves sensibles sont conservées dans l’espace autorisé, avec une référence exploitable dans le dossier. Une conclusion non vérifiée reste visible comme telle.
Cette matrice protège aussi l’équipe entrante. Elle distingue les défauts déjà présents des régressions qui pourraient apparaître ensuite et rend les échanges avec le prestataire sortant plus précis. Le constat technique doit rester distinct d’une éventuelle appréciation contractuelle des responsabilités.
Comparer finition, recadrage et reconstruction sur le travail restant
Terminer un périmètre techniquement recevable
La finition devient crédible lorsque le code se construit, que l’architecture permet le premier usage et que les écarts sont identifiables. L’estimation inclut corrections, intégrations, tests, recette et installation. Une fonction codée mais jamais reçue peut encore demander un travail significatif avant de rejoindre la production.
Réduire la première ouverture sans rompre le parcours
Le recadrage peut différer des profils, des établissements ou des options, tout en conservant un usage complet pour la population retenue. Il devient dangereux s’il retire les contrôles, les exceptions ou le support nécessaires à ce même usage. Un parcours moins large peut être utile ; un parcours qui s’arrête avant son résultat reste un prototype.
Reconstruire uniquement ce qui le justifie
Une zone peut devoir être remplacée lorsque ses limites empêchent les exigences essentielles ou rendent les corrections trop incertaines. La comparaison intègre la reprise des données, les interfaces à refaire et la capacité de l’équipe à maintenir le résultat. La refonte du logiciel métier devient alors une trajectoire à cadrer, avec ses propres risques.
Contre-intuitivement, conserver du code ne constitue pas toujours l’économie principale. Le coût caché peut résider dans l’attente d’une décision métier, la récupération d’un compte ou la disponibilité d’un tiers. Comparez les options avec les mêmes hypothèses et rendez ces délais visibles, même lorsqu’ils ne consomment pas de journées de développement.
Définir un premier lot assez petit pour être reçu
Choisissez un résultat utile et un périmètre dont les dépendances peuvent être maîtrisées. Le lot nomme la population, les fonctions, les données, les interfaces et les exclusions. Il précise également les personnes nécessaires à la recette et à la mise en service ; leurs disponibilités font partie du planning.
La réception doit pouvoir aboutir à une décision. Pour une demande d’achat, elle peut vérifier la saisie autorisée, la validation, la réception dans l’ERP, le suivi d’état et le traitement d’un refus. Une démonstration du seul formulaire ne ferme pas ce lot si la valeur attendue dépend de l’échange aval.
- À faire d’abord : rendre la construction reproductible et lever les dépendances qui empêchent le parcours retenu.
- À recevoir ensemble : le résultat métier, les contrôles de droits, les erreurs et les moyens de suivi nécessaires.
- À différer : les fonctions qui n’apportent pas de valeur à la première population réellement ouverte.
- À refuser : une ouverture dont un risque critique connu reste sans mesure, responsable ou décision explicite.
Le dossier comporte une estimation reliée aux hypothèses et un point de revue après les premières vérifications. Une découverte importante conduit à ajuster le lot ou le calendrier. Elle ne doit pas devenir un changement silencieux de qualité ou une charge absorbée sans arbitrage.
Lever les dépendances du SI avant de promettre une date
SSO, ERP, CRM, fichiers, documents et traitements différés peuvent bloquer une première livraison alors que les écrans semblent presque prêts. Recensez le responsable de chaque interface, les environnements disponibles, les droits nécessaires et les données de référence. La DSI coordonne les interventions qui relèvent de ses systèmes.
Une documentation API ne prouve pas que l’interface est ouverte sur l’installation concernée. Vérifiez les capacités, la version et les accès avec le responsable du logiciel ou son intégrateur. L’expertise intégration API et middleware sur mesure permet de traiter ces échanges dans leur contexte réel, sans présumer un connecteur natif inexistant.
L’hébergement peut rester dans le SI client ou être confié à Dawap selon le cadre retenu. Cloud, serveur dédié ou on-premise changent notamment les interlocuteurs, les accès réseau, les responsabilités et les procédures. La préparation d’un déploiement dans le SI avec la DSI aide à traiter ces préconditions avant la date d’ouverture.
Recevoir le logiciel avant sa première mise en service
La sandbox ou recette doit permettre de vérifier la version qui sera proposée à l’ouverture. Pour chaque scénario, le métier fournit l’entrée et la sortie attendue ; les responsabilités de validation sont attribuées. Les essais vérifient les droits, les données et les effets dans les systèmes reliés, tandis que la journalisation conserve les éléments nécessaires à l’explication d’un échec. La distinction entre sandbox, recette et production évite de confondre un essai de développement avec une validation métier.
Les contrôles de sécurité sont définis et autorisés à la profondeur adaptée au projet. Le guide de tests de sécurité OWASP fournit un cadre de référence pour organiser des vérifications ; citer ce guide ne transforme pas une revue limitée en certification ou en test d’intrusion complet.
Préparez la configuration, les données initiales, les comptes, la sauvegarde, la supervision et le support. Le retour arrière précise ses limites : retirer une version n’annule pas nécessairement les écritures déjà reçues par un ERP. La personne qui autorise l’ouverture doit connaître les réserves et les conditions d’arrêt.
Après l’installation, vérifiez le premier cycle réel du périmètre ouvert. Un traitement nocturne, un document ou une synchronisation peut révéler ce que la démonstration n’exécutait pas. L’observation et les personnes mobilisables sont organisées avant d’annoncer le premier lot terminé.
Arbitrer budget, planning et responsabilités pendant la relance
Le pilotage rapproche travail reçu, écarts ouverts, décisions attendues et reste à accomplir. Un référent senior explique les difficultés techniques ; un responsable métier tranche les usages et les priorités. Les décisions engageant une autre équipe sont attribuées à un interlocuteur disponible.
Le budget distingue évaluation, remise en capacité de livrer, réalisation du premier lot et exploitation après ouverture. Ajoutez la disponibilité des utilisateurs pour les essais, les coûts de services et les éventuels environnements temporaires. Une estimation de code seule peut déplacer une part importante du coût vers la DSI et les métiers.
À chaque itération, montrez ce qui est reçu sur une version identifiable, ce qui reste incomplet et ce qui modifie la trajectoire. Le sponsor doit pouvoir réduire le périmètre, financer une investigation ou arrêter une partie du projet. Un nouveau planning sans changement d’hypothèses ne résout pas un blocage déjà observé.
Éviter les erreurs qui prolongent un projet bloqué
- Confondre démonstration et livraison : exigez une version installable, des cas reçus et les dépendances réellement raccordées.
- Racheter le même périmètre sans diagnostic : identifiez les causes du blocage avant d’engager une nouvelle estimation globale.
- Ajouter des fonctions pendant la remise à plat : arbitrez leurs effets sur le premier usage et ses critères de réception.
- Ouvrir tous les accès immédiatement : attribuez les droits nécessaires et les interventions autorisées avec les responsables du SI.
- Faire porter la recette à une équipe indisponible : réservez ses créneaux ou ajustez explicitement la date proposée.
Le signal d’arrêt le plus utile est une dépendance essentielle qui reste inconnue après les investigations prévues. Il faut alors décider un complément d’analyse ou réduire le lot, plutôt que masquer cette inconnue dans une marge générale. Le résultat de l’évaluation peut légitimement être de différer une ouverture.
Plan d’action : obtenir une décision de relance exploitable
- Décrire le premier usage attendu et les personnes déjà exposées au logiciel.
- Rassembler sources, versions, environnements et interlocuteurs, puis identifier les éléments absents.
- Reproduire une version isolée et comparer les capacités aux scénarios métier retenus.
- Qualifier les écarts avec leurs preuves, leurs conséquences et leurs dépendances encore ouvertes.
- Comparer finition, réduction du périmètre et reconstruction sur les travaux restant à accomplir.
- Recevoir un premier lot, son déploiement et son suivi avant d’élargir la roadmap.
La sortie attendue est un dossier que le sponsor et l’équipe de réalisation peuvent reprendre : version évaluée, limites, choix, estimation conditionnelle, responsables et critères de réception. Si une autre personne doit tout réinterpréter après la restitution, le dossier manque encore d’éléments opérationnels.
Approfondir les décisions de reprise et de cadrage
Faire produire un diagnostic utile
Notre audit technique avant refonte ou reprise précise les investigations et les livrables à convenir. L’exemple de restitution montre comment rapprocher preuve, impact, action et décision, avant d’engager la réalisation.
Capturer la connaissance encore disponible
Le guide pour documenter une application avant le départ des sachants aide à faire expliquer les règles et les exceptions. Ces informations permettent de distinguer un défaut d’une décision métier encore valide.
Formaliser les arbitrages du premier chantier
Le cahier des charges construit avec les métiers et la DSI relie usages, périmètre et réception. Il devient pertinent lorsque l’évaluation conduit à reconstruire une partie du produit plutôt qu’à terminer simplement les travaux engagés.
Conclusion : relancer un usage recevable, avec une équipe capable de poursuivre
Un projet inachevé se reprend en rapprochant ce qui est attendu, ce qui existe et ce qui peut être démontré. La version disponible, les décisions métier et les dépendances du SI permettent de comparer des trajectoires réalistes.
Le premier lot doit fermer un parcours utile pour une population définie. Sa réception inclut les exceptions, les interfaces et les moyens d’exploitation nécessaires, afin que le service rendu dépasse le cadre d’une démonstration.
La décision reste liée aux faits découverts pendant l’évaluation. Réduire un périmètre, demander une investigation complémentaire ou différer l’ouverture peut protéger davantage le projet qu’une nouvelle date fondée sur les mêmes inconnues.
Dawap accompagne la reprise de votre application sur mesure avec une équipe senior, en dialogue avec les métiers et la DSI. Nous cadrons les éléments à vérifier, le premier résultat à recevoir et les conditions techniques qui permettront ensuite de faire évoluer le logiciel.
