Reprise d’un logiciel sur mesure : prouver la passation

Avant l’audit technique, nommez les opérations dont l’interruption aurait une conséquence immédiate : saisir une commande, préparer une livraison, facturer ou consulter un dossier. Donnez-leur un responsable métier et un résultat attendu. Demandez aussi quelles périodes compliquent une intervention : clôture comptable, paie ou pointe saisonnière. Le calendrier de transfert doit tenir compte de ces contraintes.

Une reprise peut préserver une grande partie du logiciel tout en remplaçant un composant fragile. L’examen d’une application web sur mesure devrait distinguer les défauts qui empêchent son exploitation, les risques à corriger avant la bascule et les améliorations qui peuvent attendre. Cette séparation donne un périmètre au transfert et évite de conditionner toute la reprise à une refonte générale.

Construisez l’inventaire avec un représentant de l’entreprise et les deux équipes techniques lorsque c’est possible. Pour chaque compte, inscrivez l’organisation propriétaire, l’administrateur, le moyen de récupération, le payeur et les services qui en dépendent. Un accès partagé peut fonctionner aujourd’hui tout en rendant impossible l’identification de la personne ayant modifié une configuration. Prévoyez des comptes nominatifs et une relève administrative.

Le transfert d’un dépôt ne transfère pas automatiquement tous les actifs de l’entreprise. La documentation GitHub précise des conséquences propres au transfert d’un repository; elle ne remplace pas l’inventaire de l’hébergement, des licences ou des intégrations. Vérifiez également les droits contractuels sur le code et les composants. La possession d’un fichier ne démontre pas le droit de le modifier ou de le redistribuer.

Demandez à la nouvelle équipe d’utiliser une machine ou un environnement propre et ses propres comptes. Elle doit récupérer le dépôt à la version convenue, installer les dépendances et produire un livrable exploitable. Consignez la version des outils et les étapes nécessaires. Si une commande fonctionne seulement sur l’ordinateur de l’ancien fournisseur, inscrivez ce point comme une dépendance à résoudre.

La démonstration suivante porte sur les données. Une sauvegarde annoncée comme quotidienne doit être restaurée dans un environnement isolé, puis contrôlée avec le responsable métier. Vérifiez que les dossiers et pièces jointes attendus sont présents et que les liens entre eux restent utilisables. Les recommandations NIST sur la planification de continuité aident à préparer ces exercices; elles ne prouvent pas qu’une restauration particulière a réussi.

Enfin, faites exécuter un parcours complet. Pour un CRM ou ERP sur mesure, cela peut être la création d’un dossier fictif, son approbation et son export. Utilisez des comptes aux rôles différents. Conservez un résultat observé, les journaux utiles et la décision du responsable métier. Le présent guide ne rapporte aucun essai réalisé sur un logiciel client.

Imaginons un distributeur dont l’application prépare les commandes. Le code est disponible dans un dépôt de l’entreprise, mais les notifications passent encore par le compte personnel d’un ancien administrateur. Dans un environnement d’essai, la nouvelle équipe peut créer une commande; l’envoi de confirmation échoue. Le transfert reste incomplet même si la page principale s’affiche correctement.

Dans cet exemple hypothétique, le procès-verbal prévoit la création d’un compte de messagerie appartenant à l’entreprise, la configuration des autorisations et la répétition du scénario. L’équipe conserve l’ancien parcours opérationnel jusqu’à l’acceptation. Aucun délai ni gain chiffré n’est supposé. L’intérêt de l’exercice tient à la preuve manquante et à la personne qui doit la fournir.

Une réserve indique une anomalie précise, son impact, son responsable et sa date de réexamen. Elle ne doit pas cacher une incapacité à exploiter le logiciel. Le signataire métier accepte les conséquences opérationnelles; le signataire technique confirme les preuves produites. Un refus doit décrire ce qui manque pour refaire la réception, sans transformer une hypothèse en diagnostic définitif.

Avant la bascule, déterminez à quel moment la saisie s’arrête, qui surveille le nouveau système et quel événement déclenche un retour. Une restauration ancienne peut faire disparaître des opérations récentes. Prévoyez comment retrouver et rapprocher les modifications effectuées depuis la sauvegarde. La décision doit couvrir les données autant que la version du logiciel.

Les automatisations CRM et ERP méritent leur propre inventaire : tâches planifiées, webhooks, files d’attente et reprises manuelles. Pendant un chevauchement, deux traitements peuvent lire le même événement. Vérifiez quel système reste autorisé à écrire et comment une opération déjà traitée sera reconnue. Conservez un journal des changements pendant la fenêtre de transfert.

Révoquez ensuite les anciens accès selon une liste approuvée et faites tourner les secrets concernés. Évitez une révocation prématurée qui empêcherait un retour prévu. OWASP ASVS fournit des critères utiles pour discuter des contrôles d’accès et de la journalisation. Le dossier final devrait permettre à une autre personne autorisée de retrouver les preuves sans dépendre de la mémoire du nouveau fournisseur.