Rédiger le cahier des charges d’un logiciel sur mesure

La baisse des demandes justifie de soigner votre consultation, sans présumer des prix ni des disponibilités : les annonces publiques de codeur.com relevées le 14 octobre 2026 recensent 55 annonces sur les six derniers mois, contre 109 sur les six précédents.

Ce relevé concerne le thème « cahier des charges, consultation, appel d'offres ». Il décrit les annonces observées sur cette plateforme. Il ne mesure ni l'ensemble du marché du développement logiciel, ni la charge des agences que vous contactez. Vous ne pouvez donc pas en déduire qu'un prestataire acceptera votre calendrier ou réduira son devis.

Votre levier consiste à rendre la demande facile à comprendre et à discuter. Présentez le problème rencontré, les utilisateurs concernés, les opérations à préserver et la décision attendue du futur logiciel. Ajoutez ce qui est déjà disponible : application existante, documentation, accès techniques, exemples de documents métier et interlocuteurs capables de valider les règles.

Exemple hypothétique : vous souhaitez remplacer un suivi de dossiers partagé entre plusieurs services. Écrire « centraliser les informations » laisse ouvertes les questions décisives. Décrire qui ouvre un dossier, qui le valide, ce qui bloque sa clôture et comment corriger une erreur permet au candidat de repérer les travaux nécessaires.

Demandez ensuite aux candidats de formuler leurs hypothèses et leurs réserves. Une réponse exploitable indique les informations manquantes et leurs conséquences sur l'engagement proposé. Une promesse générale de simplicité ne vous aide pas à arbitrer.

Avant d'utiliser une sélection de prestataires, préparez une version commune du dossier. Transmettez les mêmes clarifications aux candidats consultés pour que leurs réponses restent comparables. Conservez les décisions prises pendant les échanges : elles devront rejoindre les pièces contractuelles si elles modifient le besoin.

Les annonces publiques de codeur.com relevées le 14 octobre 2026 affichent 38.0 % de budgets à 1 000 € et plus, mais cette indication ne fixe pas le prix de votre cahier des charges ni celui du logiciel.

Ces budgets déclarés portent sur le thème « cahier des charges, consultation, appel d'offres ». Leur présence ne permet pas de connaître le contenu finalement commandé, le montant signé ou la qualité des livrables. Servez-vous de ce repère pour poser des questions de périmètre, sans le transformer en tarif de référence.

Dans votre consultation, distinguez ce que vous demandez pour définir le projet et ce que vous demandez pour le réaliser. Un atelier de cadrage, une description des parcours, une analyse de l'existant et un dossier utilisable par un autre prestataire ne constituent pas nécessairement la même prestation. Faites préciser les livrables remis et leurs conditions de réutilisation.

Exemple hypothétique : un devis prévoit le développement des écrans, mais laisse la préparation des données à votre équipe. Le montant ne devient comparable à une autre proposition qu'après clarification de cette charge et des vérifications attendues.

Indiquez votre enveloppe si elle constitue une contrainte, puis demandez un périmètre compatible et des arbitrages explicites. Ne laissez pas le candidat retirer discrètement la recette ou la documentation pour y entrer. Le guide des prix d'un logiciel sur mesure complète cette lecture des postes à discuter.

Vous protégez le périmètre en décrivant les résultats attendus, les exclusions et la procédure de modification dans un document accepté par les parties.

Le relevé des annonces publiques de codeur.com du 14 octobre 2026 comprend 192 annonces sur le thème « cahier des charges, consultation, appel d'offres ». Ce corpus ne fournit pas de modèle universel : votre document doit partir des opérations que votre organisation doit réellement exécuter.

Pour chaque besoin, précisez l'utilisateur, l'événement déclencheur, les informations nécessaires et le résultat observable. Décrivez aussi les refus attendus. Un logiciel ne doit pas seulement enregistrer une opération correcte ; il doit signaler une information manquante ou empêcher une validation non autorisée.

Exemple hypothétique : pour une fonction de validation de dossier, indiquez les rôles habilités, les pièces requises, les motifs de rejet et les conditions de réouverture. Précisez si la notification, l'historique et l'export font partie de la demande. Sans cette délimitation, chaque interlocuteur peut comprendre un livrable différent.

• Inscrivez les fonctions attendues et les résultats qui permettront de les accepter.
• Identifiez les interfaces, les données reprises et les dépendances à votre organisation.
• Nommez les exclusions, les hypothèses et les décisions encore ouvertes.
• Prévoyez comment une demande nouvelle sera décrite, évaluée puis autorisée.

Évitez de figer prématurément chaque détail d'écran. Vous avez surtout besoin de verrouiller les règles métier et les engagements qui influencent le coût, la recette et l'exploitation. Les choix de présentation peuvent rester discutables tant qu'ils respectent ces engagements.

Désignez enfin la personne qui arbitre pour votre entreprise. Une remarque d'utilisateur ne doit pas devenir automatiquement une commande supplémentaire. Le prestataire doit pouvoir distinguer une correction nécessaire pour respecter le périmètre d'une évolution qui exige votre accord.

Vous rendez la recette décisive en associant chaque exigence à un scénario d'essai, un résultat attendu et une règle de traitement des écarts.

Les annonces publiques de codeur.com relevées le 14 octobre 2026 comprennent 59 annonces dans la catégorie « 1 000 € à 10 000 € ». Cette catégorie budgétaire ne précise pas la place des essais : votre dossier doit donc demander explicitement ce que le prestataire prépare, exécute et corrige.

Commencez par les parcours nécessaires à l'activité. Pour chacun, décrivez les données de départ, le rôle utilisé, l'action réalisée et le résultat vérifiable. Ajoutez les erreurs plausibles, les droits insuffisants et les échanges avec les outils déjà présents. Une démonstration préparée par le développeur ne remplace pas cette vérification de vos usages.

Exemple hypothétique : un utilisateur valide un dossier incomplet. Le scénario précise que la validation doit être refusée, que le motif doit être compréhensible et que les informations déjà saisies doivent rester disponibles. La recette vérifie alors une règle métier, au lieu de se limiter à constater qu'un bouton fonctionne.

1. Faites approuver les scénarios et les résultats attendus avant les essais.
2. Préparez un environnement et des données adaptés aux situations à vérifier.
3. Consignez les écarts avec les éléments permettant de les reproduire.
4. Vérifiez les corrections et les parcours qu'elles risquent d'affecter.
5. Formalisez la décision de réception et le traitement des réserves.

Définissez dans les pièces contractuelles ce qui bloque la réception et ce qui peut faire l'objet d'une réserve. Faites également préciser les conditions de nouvelle présentation après correction. Le vocabulaire doit être partagé : une anomalie est un écart à une exigence convenue, tandis qu'une préférence nouvelle peut relever d'une évolution. Cette distinction protège autant votre décision de paiement que la conduite des échanges.

Vous devez demander une cession écrite détaillant les droits transmis : le code de la propriété intellectuelle exige un écrit depuis le 1er octobre 2016 et une délimitation des droits cédés depuis le 3 juillet 1992.

Le paiement du développement et la remise des fichiers ne suffisent pas à établir que vous disposez des droits nécessaires pour faire évoluer le logiciel. Votre cahier des charges doit demander une proposition contractuelle qui distingue les développements réalisés pour vous, les éléments préexistants du prestataire et les composants soumis à leurs propres licences.

Faites préciser les droits de reproduction, d'adaptation, de distribution et de mise à disposition en ligne lorsque vos usages les nécessitent. Le domaine d'exploitation doit être délimité quant à son étendue, sa destination, son lieu et sa durée. Ces éléments doivent figurer dans l'acte de cession, avec une mention distincte pour chaque droit cédé.

Exemple hypothétique : vous voulez confier ultérieurement la maintenance à un autre prestataire. La réception d'une archive du code ne répond pas, à elle seule, à cette intention. Le contrat doit vous donner les droits utiles, et la livraison doit contenir les éléments techniques permettant au repreneur de travailler.

Demandez aussi un inventaire des composants et de leurs licences. Les obligations dépendent notamment des composants utilisés et de la manière dont le logiciel est distribué ou accessible. Une formule générale promettant que « tout le code vous appartient » ne remplace pas cet inventaire.

Au stade du choix, comparez les restrictions annoncées et leurs effets sur vos projets : modification, hébergement, maintenance et transfert. Faites examiner la rédaction adaptée à votre contrat avant signature. Votre objectif opérationnel est clair : pouvoir utiliser, corriger et transmettre le logiciel dans les conditions que vous avez effectivement négociées.

Vous préparez le changement de prestataire en exigeant des livrables de reprise et un plan de transfert, comme le prévoit pour les marchés concernés le CCAG-TIC 2021, article 42, vérifié le 1er octobre 2026.

Le dossier fourni décrit un plan de réversibilité annexé au CCAP, qui peut couvrir les exécutables, les codes sources, la documentation, le paramétrage et les données dans des formats documentés. Pour votre consultation publique, indiquez ce qui doit être transféré, par qui et dans quelles conditions. Pour un contrat privé, décrivez également ces attentes dans les pièces négociées.

La réversibilité doit être préparée pendant la réalisation. Demandez où sont conservés les dépôts de code, comment les accès sont administrés et comment la documentation sera tenue à jour. Une documentation promise uniquement à la sortie risque de laisser les connaissances dispersées entre les intervenants.

Exemple hypothétique : une autre équipe reçoit le code, mais ignore les paramètres nécessaires pour démarrer l'application. Le transfert reste incomplet pour votre usage. Prévoyez une vérification de reprise : installation à partir des éléments livrés, restauration des données et exécution d'un parcours métier convenu.

• Listez les fichiers, configurations et documents attendus.
• Précisez les formats d'export et les informations nécessaires pour les interpréter.
• Définissez l'assistance au repreneur et ses modalités de facturation.
• Organisez le transfert des accès et la clôture des accès devenus inutiles.

Si le code n'est pas remis dans le cadre de l'offre, demandez comment l'accès serait organisé en cas de défaillance ou d'arrêt de maintenance. Un entiercement doit préciser les éléments déposés, leur mise à jour et les conditions d'accès. La préparation d'une reprise de logiciel commence ainsi dès la commande initiale, avant qu'un changement d'équipe devienne urgent.

Vous devez prévoir un contrat écrit de sous-traitance lorsque le prestataire traite des données personnelles pour votre compte, conformément à l'article 28 du RGPD, vérifié le 12 octobre 2026.

Le cahier des charges doit permettre de décrire l'objet, la durée, la nature et la finalité du traitement, ainsi que les types de données et les catégories de personnes concernées. Cette description sert à identifier les engagements nécessaires au développement, à l'hébergement et à la maintenance. Elle doit correspondre aux accès réellement prévus.

Demandez la liste des sous-traitants envisagés et la procédure applicable à leur autorisation écrite préalable. Précisez les instructions documentées, la confidentialité, la sécurité, l'aide apportée pour répondre aux demandes des personnes et les modalités d'audit. Une annexe générique ne résout pas les questions laissées ouvertes par l'architecture proposée.

Exemple hypothétique : un intervenant de maintenance souhaite utiliser une copie des dossiers clients pour reproduire une anomalie. Le dossier doit préciser comment cet accès est autorisé, quelles données sont nécessaires et comment leur utilisation prend fin. Vous évitez ainsi que les pratiques de dépannage soient décidées sans cadre partagé.

Traitez séparément l'export opérationnel et la fin du traitement. L'export doit vous permettre de poursuivre votre activité avec des données compréhensibles. Le contrat doit également prévoir leur suppression ou leur restitution, à votre choix, en fin de prestation. Faites préciser le sort des copies utilisées pour les essais et la maintenance.

Pour comparer les offres, demandez enfin qui répond aux demandes et quels documents seront remis. Ces responsabilités doivent apparaître dans les propositions, avec les prestations associées. Vous pourrez alors vérifier que l'organisation annoncée reste compatible avec votre exploitation et votre sortie du contrat, sans découvrir ces dépendances après la livraison.

Vous devez relier chaque poste du devis à un livrable, à une responsabilité et à une condition de validation pour comprendre ce que le calendrier engage réellement.

Les annonces publiques de codeur.com relevées le 14 octobre 2026 comprennent 14 annonces dans la catégorie « 10 000 € et plus ». Ce seuil déclaré ne renseigne ni le délai de livraison ni l'étendue des prestations : ces engagements doivent être obtenus dans l'offre qui répond à votre dossier.

Demandez un calendrier fondé sur les dépendances identifiées. Le prestataire doit préciser les informations, accès, arbitrages et validations qu'il attend de votre organisation. De votre côté, vérifiez que les personnes concernées pourront participer. Un planning ne devient pas fiable parce qu'une date finale est inscrite dans un tableau.

Exemple hypothétique : la connexion à votre logiciel existant dépend d'une documentation que vous ne détenez pas encore. Le devis doit expliquer comment cette incertitude sera levée et ce qui restera à décider ensuite. Il ne doit pas présenter l'intégration comme un engagement entièrement défini tout en laissant ses conditions dans une réserve vague.

Faites distinguer les travaux inclus, les prestations optionnelles et les interventions déclenchées sur accord. Pour chaque livrable, vérifiez les critères d'acceptation, les dépendances et les modalités de paiement proposées. Rapprochez les exclusions du périmètre fonctionnel : une exclusion technique peut empêcher un résultat métier pourtant annoncé.

Décrivez aussi le passage en exploitation. Qui prépare la mise en service, accompagne les utilisateurs et traite les anomalies signalées après livraison ? Distinguez les corrections dues au titre du contrat des évolutions et de la maintenance future. Avant de comparer les montants, rapprochez les offres de votre dossier et faites consigner les écarts. Cette lecture vous permet de négocier un engagement compréhensible, avec des décisions identifiées lorsque le besoin reste ouvert.

Vous devez spécifier vos besoins métier et vos contraintes avant de choisir une solution, puis approfondir les points qui départagent création, adaptation et conservation de l'existant.

Cette comparaison doit inclure les conditions d'accès au code : le dossier sur la propriété intellectuelle cite la GNU GPL version 3 du 29 juin 2007 et distingue ses obligations de celles de la GNU AGPL version 3. Ces licences ne se résument pas à une promesse de gratuité ou à un accès automatique à tous les éléments du service.

Le dossier précise que la distribution sous forme d'objet d'un programme sous GPL impose de fournir le code source correspondant selon les modalités prévues. Pour une version modifiée d'un programme sous AGPL, les utilisateurs qui interagissent avec elle à distance par un réseau doivent pouvoir obtenir gratuitement le code source correspondant. Demandez donc un inventaire contextualisé des licences et de leurs implications dans l'usage proposé.

Exemple hypothétique : votre besoin peut être couvert par l'adaptation d'un outil existant ou par un développement spécifique. Comparez les parcours couverts, les écarts restants, les possibilités de modification et les conditions de sortie. Un besoin non négociable doit rester visible dans les propositions, même si un candidat recommande une autre architecture.

Évitez de commander une description détaillée d'écrans qui serait inutilisable pour discuter ces alternatives. Commencez par les résultats attendus et demandez aux candidats d'expliquer comment ils les atteignent. Approfondissez ensuite les interfaces, les données et les règles qui créent des risques de réalisation.

Le comparatif entre sur mesure et progiciel peut structurer cet arbitrage. Votre cahier des charges sera prêt lorsque les candidats pourront annoncer leurs écarts, leurs engagements de recette et leurs conditions de transfert sur une base commune. Vous gardez ainsi la possibilité de choisir une solution différente sans perdre les exigences qui protègent votre activité.