Passation d’un logiciel interne : checklist de réception

01 · Inventaire

Les quatre ensembles à recevoir

On parle souvent de « remettre le code ». C’est nécessaire, mais insuffisant : une application vit aussi grâce à un hébergement, des services tiers, des réglages, des habitudes d’exploitation et des personnes qui savent quoi faire quand quelque chose casse.

Schéma : chaque ensemble remis se termine par un contrôle effectué par votre équipe.

1 Le code et ce qui permet de le reconstruire

Le code source seul ne suffit pas à reconstruire une application. Demandez le dépôt complet, avec son historique, hébergé sur un compte qui appartient à votre entreprise.

Les scripts de construction, de déploiement et de migration de la base de données.
La liste des dépendances et de leurs versions, avec les licences des bibliothèques utilisées.
Les tests automatisés existants et la façon de les lancer.
Un fichier de configuration d’exemple, sans secret réel, qui liste les variables à renseigner.
La version exacte qui tourne en production, identifiée dans le dépôt.

La propriété du code dépend du contrat. Pour un développement sur mesure, vérifiez la clause de cession des droits : la remise d’une copie n’en tient pas lieu. Cet article ne remplace pas l’avis d’un juriste.

2 Les accès, transférés plutôt que partagés

Une application dépend de comptes que l’on oublie facilement parce qu’ils ne se voient pas à l’écran. Faites-en l’inventaire complet :

hébergement, base de données et sauvegardes ;
nom de domaine, DNS et certificats ;
services tiers : envoi d’emails, stockage de fichiers, paiement, cartographie, IA, API métier ;
dépôt de code, outils d’intégration continue, surveillance et journaux d’erreurs ;
comptes administrateurs de l’application elle-même.

Pour chacun, le bon résultat est un compte au nom de l’entreprise, facturé à l’entreprise, avec au moins deux administrateurs internes. Recevoir un mot de passe par email n’est pas un transfert. Une fois la propriété transférée, les secrets (clés d’API, mots de passe techniques) sont renouvelés et les accès personnels du prestataire retirés ou limités à ce qui reste convenu.

3 Une documentation par usage

Une documentation utile répond aux questions de ceux qui vont s’en servir. Distinguez au moins quatre publics :

Utilisation: Les tâches métier pas à pas, avec les cas particuliers et les erreurs fréquentes.
Administration: Créer un utilisateur, régler un paramètre, importer ou exporter des données, gérer les droits.
Exploitation: Déployer, sauvegarder, restaurer, surveiller, réagir aux incidents connus.
Technique: Architecture, modèle de données, règles métier, décisions importantes et leurs raisons.

Les raisons des choix comptent autant que leur description : ce sont elles qui évitent à un futur développeur de casser une règle métier qu’il croit inutile.

4 Les responsabilités, écrites noir sur blanc

La question la plus souvent oubliée : qui fait quoi à partir de la date de passation ? Listez les tâches récurrentes et mettez un nom en face de chacune.

répondre aux questions des utilisateurs ;
administrer les comptes et les paramètres ;
vérifier les sauvegardes et payer les services tiers ;
appliquer les mises à jour de sécurité ;
corriger les anomalies et décider des évolutions.

Si le prestataire garde un rôle après la passation (garantie, accompagnement, maintenance), son périmètre et sa durée sont écrits. Sinon, chacun croit que l’autre s’en occupe.

02 · Outil

Checklist de réception : les contrôles avant d’accepter

Chaque ligne décrit un geste à réaliser par votre équipe, pas un document à cocher sur une liste. Cochez au fil de vos vérifications : le compteur se met à jour dans votre navigateur, rien n’est enregistré ni envoyé.

03 · Décision

Accepter, accepter avec réserves ou refuser

La réception n’est pas un tout-ou-rien. Les contrats informatiques distinguent généralement trois issues, à condition qu’elles aient été prévues : l’acceptation sans réserve, l’acceptation avec des réserves identifiées, et le refus motivé lorsqu’un défaut empêche d’utiliser l’application pour ce à quoi elle sert.

Accepter

Les contrôles essentiels sont réalisés par votre équipe. Les écarts restants sont mineurs et n’empêchent ni l’usage, ni l’exploitation.

Accepter avec réserves

L’application est utilisable, mais un élément manque : une procédure non testée, un compte encore au nom du prestataire, une documentation incomplète. Chaque réserve a un responsable, une date et une manière de vérifier sa levée.

Refuser, motif à l’appui

Un défaut bloque l’usage prévu, ou un élément vital est absent : impossible de déployer, de restaurer une sauvegarde ou d’accéder à l’hébergement. Le refus décrit précisément ce qui manque.

Ce que le procès-verbal doit contenir

la référence du contrat ou du devis, et la version livrée ;
les contrôles réalisés, par qui et quand ;
la décision et la liste des réserves, avec responsable et échéance ;
la liste des accès transférés et de ceux conservés par le prestataire ;
la date à partir de laquelle les responsabilités changent de mains.

Une mise en service ne vaut pas automatiquement réception lorsque le contrat distingue les deux. Mais utiliser l’application et payer sans émettre de réserve peut être interprété comme une acceptation. Formalisez vos réserves par écrit, datées, avant le paiement final, et faites relire le contrat par un juriste en cas de doute.

04 · Continuité

Garantir la continuité du service pendant et après la passation

La continuité du service dépend aussi des renouvellements, des destinataires des alertes et de la restauration des sauvegardes. Vérifiez ces points pendant la passation, en plus du fonctionnement du code.

Les échéances invisibles. Domaine, certificats, abonnements, cartes bancaires expirées : notez chaque date dans un agenda partagé de l’entreprise, pas dans celui d’une personne.
Les alertes orphelines. Vérifiez où arrivent les emails d’erreur, les alertes de surveillance et les avertissements des services tiers. Redirigez-les vers une adresse d’équipe.
La sauvegarde théorique. Une sauvegarde n’existe vraiment qu’une fois restaurée avec succès. Faites l’essai pendant la passation, pas le jour d’une panne.
La personne unique. Si une seule personne interne sait administrer l’application, la dépendance a simplement changé de nom. Prévoyez un suppléant formé.
Le gel des évolutions. Évitez de livrer une nouvelle fonctionnalité pendant la semaine où les accès changent de mains. Séparez les deux opérations.

05 · Maîtrise

Détenir l’application ou la maîtriser

Recevoir les fichiers et les comptes vous met en possession de l’application. La propriété des droits sur le code est une autre question : elle dépend de la cession prévue au contrat. Et la maîtrise vient encore après, quand votre organisation sait prendre des décisions au sujet de l’application.

Différence entre détenir et maîtriser une application interne
Sujet	Vous détenez	Vous maîtrisez
Code	Le dépôt est sur votre compte. Vos droits dessus dépendent de la cession prévue au contrat.	Une personne de votre choix peut le modifier et le déployer.
Données	La base est hébergée chez vous.	Vous savez l’exporter, la restaurer et expliquer chaque champ important.
Coûts	Vous payez les factures.	Vous savez quel service coûte quoi et ce qui se passe si vous l’arrêtez.
Évolutions	Vous pouvez demander une modification.	Vous savez estimer son effet sur les règles métier existantes.
Prestataire	Vous pouvez en changer.	Un nouveau développeur reprend le travail à partir de la documentation.

La passation vous met en possession de l’application. La maîtrise se construit ensuite, et fait l’objet de deux articles : transférer un logiciel sur mesure à votre équipe et organiser la formation de handover par rôle.

Chez Mexar

Ce que nous transmettons à la fin d’une réalisation

Avec la méthode ROI-first, le client reçoit l’application, son code, une documentation pensée pour être reprise par un développeur comme par un assistant IA, et la maîtrise des services tiers utilisés. Vous pouvez poursuivre avec nous ou confier la suite à un autre développeur compétent.

Le parcours prévoit un accompagnement à la prise en main. Sa durée et son périmètre sont fixés dans le devis, selon l’application et votre équipe : nous ne les annonçons pas de façon générale.

Décrire votre processus Voir la méthode ROI-first

Passation d’un logiciel interne : ce que vous devez recevoir et vérifier avant d’accepter