Appel d'offres pour une application mobile : cahier des charges et sélection

Un bon cahier des charges n'a pas réponse à tout

Une entreprise demande une application de réservation à trois agences. La première imagine une application client, un planning pour le personnel et une interface d'administration. La deuxième suppose que le système métier existant fournit déjà les disponibilités. La troisième chiffre surtout la partie visible sur mobile. Les trois dossiers peuvent être sérieux tout en parlant de périmètres incompatibles.

Le cahier des charges et la consultation servent d'abord à empêcher ce malentendu. Leur rôle n'est pas de prouver que le commanditaire connaît déjà l'architecture idéale. Ils posent une base commune, rendent les hypothèses visibles et donnent aux prestataires assez d'espace pour exercer leur jugement.

Dans une entreprise privée, on peut parler de consultation, d'appel d'offres ou de demande de proposition. Il n'est pas nécessaire de reproduire les formalités d'un marché public. La démarche devient utile lorsque plusieurs directions participent au choix, que l'application touche au système d'information ou que plusieurs agences doivent réellement être comparées. Pour une idée encore fragile, un brief d'estimation suivi d'un cadrage rémunéré sera souvent plus fécond qu'un dossier de cinquante pages.

Commencez par l'usage, pas par la liste des écrans

Avant de rédiger les rubriques, racontez deux à cinq parcours complets. Qui déclenche l'action ? De quelles informations cette personne dispose-t-elle ? Que se passe-t-il si la situation sort du cas idéal ? Qui intervient côté métier ? Comment sait-on que la tâche est terminée ?

Une ligne comme « notifications push » ne permet pas de comprendre le produit. « Prévenir le patient la veille, lui permettre de déplacer le rendez-vous dans la limite autorisée et signaler le créneau libéré au secrétariat » donne déjà matière à concevoir, tester et discuter les responsabilités.

Cette approche évite aussi de confondre les documents. Le PRD aligne l'organisation sur le problème, les utilisateurs et les priorités. La spécification fonctionnelle ou technique précise le comportement, les données et la recette. La consultation demande à plusieurs prestataires de proposer une démarche et d'en justifier les choix. Enfin, l'offre retenue est clarifiée avant d'alimenter le contrat.

La trame de PRD pour une application aide à préparer le besoin en interne. Le modèle de spécification mobile devient utile lorsque les règles sont assez mûres. Le cahier des charges peut joindre ces pièces sans les dupliquer.

Une préselection courte améliore les réponses longues

Répondre sérieusement mobilise des profils expérimentés. Envoyer le même questionnaire à quinze agences récompense surtout celles qui disposent d'une grosse équipe commerciale.

Organisez d'abord une prise de contact légère. Deux pages suffisent pour présenter l'activité, le problème, les utilisateurs, les principales contraintes et la période de démarrage. Demandez quelques réalisations pertinentes, la disponibilité, la composition probable de l'équipe, la langue de travail et les raisons éventuelles de ne pas candidater.

La pertinence d'une référence se juge sur les difficultés traitées. Pour un marketplace, une expérience des rôles, des paiements, de la modération et des litiges peut compter davantage qu'un projet au graphisme proche dans le même secteur.

La consultation complète est ensuite réservée à une liste courte. Tous les candidats reçoivent les mêmes annexes, le même calendrier et le même interlocuteur. L'effort demandé devient raisonnable et les réponses gagnent en profondeur.

Les neuf parties qui donnent une base commune

Le dossier n'a pas besoin d'être volumineux. Il doit couvrir les sujets que les agences interpréteraient autrement en silence.

1. Contexte et déclencheur. Présentez l'activité, le fonctionnement actuel, le problème et la raison d'agir maintenant.
2. Utilisateurs et parcours. Décrivez les rôles et quelques usages de bout en bout, y compris une exception importante.
3. Résultat attendu. Nommez le changement observable qui rendrait la première version utile.
4. Périmètre initial. Séparez le nécessaire, les variantes souhaitées et les sujets explicitement reportés.
5. Existant. Indiquez les API, le site, le CRM, les paiements, les données, les contenus, la marque et les interlocuteurs disponibles.
6. Contraintes fermes. Plateformes, sécurité, confidentialité, accessibilité, langues, fonctionnement hors connexion ou parc d'appareils, lorsqu'ils comptent réellement.
7. Répartition du travail. Précisez ce que fournira votre organisation et demandez qui porte le produit, l'UX, le développement, les tests, la publication et le support.
8. Pérennité. Abordez les dépôts de code, comptes cloud et stores, fichiers sources, documentation, briques tierces et transfert.
9. Règles de la consultation. Trame attendue, questions, calendrier, soutenance, critères et décision.

Ne masquez pas les zones inconnues. Signalez-les et demandez aux candidats comment ils les réduiraient : atelier, prototype, audit d'API, échantillon de données ou test utilisateur. Une incertitude reconnue se travaille. Une certitude inventée réapparaît pendant le projet.

Imposez une trame, pas une solution

Chaque offre devrait suivre le même ordre : compréhension du besoin, périmètre proposé, exclusions, hypothèses numérotées, étapes, équipe nominative, dépendances côté client, approche technique, assurance qualité, mise en production, risques, propriété, support et volet commercial.

Les hypothèses numérotées sont très pratiques. Si l'on découvre que le logiciel métier ne dispose pas de l'API attendue, tous les candidats peuvent revoir l'hypothèse H-05. La clarification ne se perd pas entre une réunion et trois fils de messagerie.

Demandez aussi de qualifier chaque capacité : incluse, optionnelle, à clarifier ou déconseillée. Une agence qui explique pourquoi elle supprimerait une fonctionnalité peut mieux protéger le produit qu'une agence qui répond oui à tout.

La grille de choix se prépare à froid

Définissez les critères avant d'ouvrir les dossiers. Une fois séduits par une présentation, nous sommes tous tentés de donner plus de poids à ce qu'elle met en valeur.

Une application médicale ou financière accordera davantage de poids aux risques et aux preuves. Un pilote limité pourra favoriser la disponibilité et la capacité à tester vite une hypothèse. La grille doit traduire la décision réelle, pas fabriquer une précision mathématique.

Faites noter les offres séparément par au moins deux personnes. Les écarts sont instructifs : l'une a pu être convaincue par la marque, tandis que l'autre a constaté que les développeurs affectés au projet n'étaient jamais identifiés.

Les réponses aux questions doivent profiter à tous

Les questions des candidats révèlent les faiblesses du cahier des charges. Tenez un journal commun et transmettez les réponses qui modifient le besoin, les contraintes ou les responsabilités. Si une agence apprend seule que l'inscription peut être évitée, les offres ne sont plus établies sur la même base.

Il ne s'agit pas de dévoiler l'idée originale d'un prestataire. On partage les faits du commanditaire. Lorsqu'une précision change fortement le projet, laissez le temps de corriger l'hypothèse concernée et, si nécessaire, l'offre.

Une réunion de lancement de la consultation est souvent utile. Son compte rendu doit néanmoins rejoindre le dossier commun. Ce document restera la mémoire du choix bien après les visioconférences.

La soutenance doit ressembler à une séance de travail

Au lieu de demander une nouvelle présentation générale, proposez aux finalistes un cas difficile : un paiement est confirmé mais la commande ne l'est pas, deux opérateurs réservent la dernière place, le réseau disparaît au milieu d'une action, ou une mauvaise décision d'administration doit être annulée sans perdre la trace.

Invitez les personnes qui interviendraient réellement. On ne cherche pas une réponse parfaite en trente minutes. On observe la qualité des questions, la place donnée à l'utilisateur et à l'exploitation, la façon de séparer faits et hypothèses, et la capacité à proposer une vérification simple.

Pour les références, remplacez « avez-vous été satisfait ? » par des questions concrètes : qu'est-ce qui a changé après la signature ? Comment les mauvaises nouvelles ont-elles été annoncées ? L'équipe présentée est-elle restée ? Que pouviez-vous encore exploiter seul à la fin ?

Reconstituez un périmètre commun avant de comparer

Placez les offres dans une même vue : rôles, plateformes, backend, interface d'administration, intégrations, design, reprise de données, analytics, tests, stores, documentation et support. Pour chaque ligne, notez les exclusions, les options et ce qui dépend de vos équipes.

Ne sanctionnez pas une réserve honnête. « Nous devons auditer l'API avant de confirmer le mode hors connexion » vaut mieux qu'un engagement ferme fondé sur une API imaginaire. Comparez plutôt la manière proposée pour lever le doute.

Notre article sur le forfait et la régie montre pourquoi le cadre contractuel dépend du niveau d'incertitude. La consultation doit rendre cette incertitude visible avant de chercher à la répartir.

Préparez la recette et le transfert dès la consultation

Demandez comment seront contrôlés les dépôts de code, les comptes Apple et Google, l'hébergement, la base de données, les domaines, les outils de mesure, les certificats et les services tiers. Listez aussi les éléments attendus à chaque jalon accepté : code, maquettes éditables, instructions de compilation, dépendances, preuves de test et limites connues.

Le guide de l'OMPI sur les contrats mobiles distingue le code créé pour le projet, les briques antérieures du prestataire, l'open source et les composants tiers. Les droits ne sont pas identiques. Le cahier des charges ne remplace pas le conseil juridique, mais il évite que cette question arrive après la sélection.

La check-list de documentation et de transfert détaille la continuité technique. La check-list du contrat de développement prépare les points à soumettre au juriste.

Une trame courte à reprendre

Pour démarrer, utilisez cet ordre : activité et raison du projet ; utilisateurs et parcours ; résultat recherché ; première version et hors-périmètre ; systèmes et données existants ; responsabilités ; contraintes ; questions aux candidats ; preuves demandées ; processus de clarification ; format de réponse ; grille et calendrier de décision.

Joignez peu de documents, mais donnez-leur un rôle clair : parcours, schéma du système actuel, échantillon de données, éléments de marque ou extrait d'analytics. Un dossier partagé rempli de fichiers sans légende n'est pas un cahier des charges plus précis.

Les réponses qui doivent inquiéter

Une offre faible paraphrase le besoin, promet toutes les fonctions sans arbitrage ou recommande une technologie sans relier le choix aux contraintes. Soyez également prudent lorsque les profils seniors disparaissent après la soutenance, que les tests sont résumés par « inclus », ou que la propriété du code n'est liée à aucun compte ni livrable concret.

Demandez un exemple anonymisé de critère de recette, de registre de risques, de check-list de publication ou d'index de transfert. Vous ne collectionnez pas des modèles. Vous vérifiez que la méthode annoncée produit des traces exploitables.

Comment Appfyl traite une consultation

Nous vérifions d'abord que la première version forme un produit cohérent. Nous relions les parcours visibles aux opérations d'administration, aux intégrations, aux cas inhabituels et aux dépendances du client. Nous pouvons alors distinguer ce qui est inclus, ce qui doit être vérifié et ce qui gagnerait à attendre.

Si le besoin n'est pas encore formalisé, le questionnaire Appfyl recueille les fonctions et le contexte libre. Pour préparer la soutenance, ajoutez les questions à poser à une agence mobile.

Voir comment Appfyl transforme un périmètre en produit lancé. Voir les cas Appfyl.

Questions fréquentes