Pourquoi le choix technologique ne se décide pas en début de projet
Il y a une scène qui se rejoue à peu près chaque mois dans les cabinets de conseil et les agences digitales. Un dirigeant arrive avec une idée claire, un budget approximatif et une phrase toute faite : « on veut une application mobile, native, iOS et Android ». La conversation démarre donc par la réponse. Pas par la question.
Et c'est précisément là que les projets dérapent.
L'erreur de séquencement la plus fréquente : arbitrer la techno avant d'avoir écrit les usages
Choisir une technologie mobile avant d'avoir décrit ce que les gens vont réellement faire avec l'application, c'est comme choisir un véhicule avant de savoir si on transporte des palettes, des enfants ou des invendus de marché. Le raisonnement paraît évident une fois posé à plat. Il est pourtant contourné dans une large majorité des consultations.
Pourquoi ? Parce que la technologie rassure. Elle donne une prise concrète sur un projet encore flou. Dire « application native » sonne sérieux, solide, professionnel. Dire « on ne sait pas encore, ça dépendra des parcours » sonne hésitant, alors que c'est en réalité la posture la plus mature.
Le coût de cette inversion se paie plus tard. Souvent au moment de la recette, parfois à la première grosse évolution, presque toujours au moment de la facture de maintenance annuelle.
Ce que révèle un appel d'offres qui impose « une app native iOS et Android » dès la première ligne
Un cahier des charges qui verrouille la technologie en page 2 raconte quelque chose sur son auteur. Pas nécessairement quelque chose de négatif, d'ailleurs. Parfois, la contrainte est légitime et documentée : un usage terrain sans réseau, un capteur exotique, une exigence de certification. Dans ce cas, tant mieux, l'arbitrage a été fait en amont.
Mais dans la plupart des dossiers, ce verrouillage traduit trois choses. Une influence extérieure, souvent un précédent prestataire ou un article lu en diagonale. Une confusion entre « application » et « présence sur les stores ». Et parfois, plus simplement, la volonté d'avoir un projet qui ressemble à ceux des concurrents.
Les prestataires sérieux le repèrent immédiatement. Certains le disent. Beaucoup se taisent, parce qu'un client qui a déjà décidé est un client plus facile à chiffrer.
Le cahier des charges comme outil de décision, pas comme document de commande
Il faut changer de regard sur ce document. Un cahier des charges n'est pas un bon de commande détaillé, c'est un instrument de clarification. Il sert d'abord à l'organisation qui l'écrit, avant de servir aux prestataires qui le lisent.
Rédigé correctement, il oblige à trancher des questions qu'on préférerait repousser. Qui utilise l'outil, dans quelles conditions, à quelle fréquence, avec quel niveau d'urgence. Ces réponses-là déterminent la technologie. Pas l'inverse.
Les six questions à trancher avant toute discussion technique
Ce qui suit n'est pas une checklist décorative. Chacune de ces six questions élimine ou valide des scénarios techniques entiers. Répondez-y honnêtement, avec des chiffres quand c'est possible, et la moitié du travail d'arbitrage sera déjà faite.
1. Quelle est la fréquence d'usage réelle attendue ?
Usage quotidien, hebdomadaire ou ponctuel : trois logiques d'installation différentes
Une application ouverte tous les jours justifie une icône sur l'écran d'accueil. L'utilisateur consent à l'installation parce qu'il sait qu'il y reviendra. Le rapport effort/bénéfice penche du bon côté.
Une application ouverte une fois par mois se fait désinstaller au premier manque de place. Une application ouverte deux fois dans une vie ne devrait probablement jamais demander d'installation du tout.
Soyez réaliste sur ce point. Les projections d'usage sont presque toujours optimistes d'un facteur trois. Prenez votre estimation, divisez-la, et raisonnez sur ce chiffre-là.
Le coût d'acquisition d'une installation sur les stores face au coût d'une URL partagée
Convaincre quelqu'un d'installer une application coûte de l'argent. Beaucoup d'argent, dans certains secteurs. Chaque étape du tunnel perd du monde : voir la publicité, cliquer, arriver sur la fiche store, accepter le téléchargement, ouvrir, créer un compte. Le taux de conversion global est souvent brutal.
Une URL, elle, se partage dans un message, un e-mail, un QR code sur une affiche. Zéro friction d'installation. L'utilisateur est dans le service en deux secondes.
Cette différence de coût d'entrée est un critère business majeur, et elle est presque systématiquement absente des cahiers des charges. Étrange, non ? On chiffre le développement au jour près, et on ignore combien coûtera l'acquisition d'un utilisateur.
2. L'application a-t-elle besoin du matériel du téléphone ?
Inventaire des capteurs et fonctions à lister explicitement : caméra, GPS en tâche de fond, Bluetooth, NFC, biométrie, accéléromètre
Faites la liste. Vraiment la liste, capteur par capteur, avec pour chacun une phrase décrivant l'usage précis. Pas « géolocalisation » mais « suivre la position du technicien pendant sa tournée, même quand l'écran est éteint ».
Cette nuance change tout. Récupérer une position ponctuelle quand l'utilisateur appuie sur un bouton : accessible partout, y compris sur le web. Suivre une position en continu, application fermée, écran verrouillé, pendant six heures : là, on entre dans un autre monde, avec ses contraintes de batterie, ses autorisations système et ses restrictions de plateforme.
Le NFC, le Bluetooth basse consommation, la lecture de badges, l'accès à des périphériques industriels : autant de fonctions où le natif garde une avance nette, voire un monopole selon les cas.
Distinguer « utiliser la caméra » et « traiter un flux vidéo en temps réel » : le niveau d'accès change tout
Prendre une photo et l'envoyer sur un serveur, c'est du web depuis longtemps. Scanner un code-barres dans un navigateur, c'est faisable aujourd'hui, avec des performances honnêtes dans des conditions correctes.
Analyser un flux vidéo en direct pour y détecter des objets, appliquer un filtre de réalité augmentée, mesurer une pièce en pointant le téléphone : on parle d'autre chose. Accès bas niveau, calcul intensif, optimisation matérielle. Le natif reprend l'avantage, et il le garde.
Écrivez donc le verbe exact. « Utiliser la caméra » ne veut rien dire. « Scanner jusqu'à deux cents codes-barres par heure dans un entrepôt mal éclairé » veut dire quelque chose.
3. Que se passe-t-il hors connexion ?
Consultation hors ligne, saisie hors ligne, synchronisation différée : trois exigences de complexité croissante
Trois niveaux, trois budgets très différents.
Consulter des contenus déjà chargés sans réseau : simple, toutes les technologies le permettent, le mécanisme de cache suffit.
Saisir des données hors ligne et les conserver localement : plus exigeant, mais gérable. Il faut un stockage local fiable et une gestion des états.
Synchroniser ces saisies au retour du réseau, en gérant les conflits, les doublons, les modifications concurrentes sur le même enregistrement : c'est de l'ingénierie sérieuse. C'est souvent le poste de coût le plus sous-estimé d'un projet mobile métier. Et c'est aussi celui qui génère le plus de bugs en production, parce qu'il est difficile à tester exhaustivement.
Les métiers terrain, le sous-sol, l'entrepôt, la zone blanche : quand l'offline n'est pas une option
Un plombier dans une cave. Un technicien dans un local technique blindé. Un livreur dans une zone rurale mal couverte. Un opérateur dans un entrepôt métallique où le réseau ne passe pas malgré trois antennes.
Dans ces contextes, le hors ligne n'est pas un confort, c'est la condition de fonctionnement de l'outil. Une application qui affiche un message d'erreur réseau à un technicien en intervention finit désinstallée avant la fin de la semaine, remplacée par un carnet et un stylo.
Si votre projet entre dans cette catégorie, dites-le en gras dans le cahier des charges. C'est le genre d'exigence qui restructure toute l'architecture.
4. Quelle est la stratégie de notification ?
Notification transactionnelle, marketing ou critique : ce que chacune impose techniquement
Une notification qui confirme une commande peut arriver avec deux minutes de retard, personne ne s'en apercevra. Une notification qui pousse une promotion peut ne jamais arriver, l'impact business est marginal. Une notification qui alerte un astreinte sur une panne critique doit arriver, immédiatement, et de façon garantie.
Ces trois cas n'ont pas les mêmes exigences de fiabilité, ni les mêmes besoins d'infrastructure. Classez vos notifications avant de discuter technique.
L'état réel du support des notifications web sur iOS et ses contraintes
Il faut être précis, parce que le sujet a beaucoup évolué et que les idées reçues persistent. Les notifications web fonctionnent aujourd'hui sur iOS, mais uniquement si l'utilisateur a explicitement ajouté le site à son écran d'accueil. Pas de raccourci, pas de notification.
Cette condition n'est pas anodine. Elle suppose une manipulation que la plupart des utilisateurs ne connaissent pas, et qu'il faut donc leur expliquer dans l'interface. Le taux d'adoption chute mécaniquement.
Si les notifications sont au cœur de votre modèle d'usage, sur une cible grand public majoritairement iOS, cette contrainte pèse lourd dans l'arbitrage. Si elles sont un confort secondaire, elle pèse beaucoup moins.
5. Quelles sont les exigences de performance et de fluidité perçue ?
Animations, transitions, listes longues, rendu graphique : là où l'écart se voit encore
L'écart de performance entre natif et web s'est considérablement réduit. Il n'a pas disparu.
Il reste visible sur les listes très longues avec défilement rapide, sur les animations complexes enchaînées, sur les transitions entre écrans qui doivent paraître instantanées, sur tout ce qui touche au rendu graphique intensif ou à la 3D.
Sur une application de saisie de formulaires, de consultation de documents, de suivi de commandes ? L'écart est imperceptible pour l'utilisateur final. Vraiment imperceptible, même sur des terminaux d'entrée de gamme.
Distinguer performance mesurée et performance ressentie par l'utilisateur final
Voilà une distinction que les équipes techniques oublient et que les utilisateurs, eux, vivent tous les jours.
Une application peut charger en 1,2 seconde et paraître lente parce qu'elle affiche un écran blanc pendant tout ce temps. Une autre peut charger en 2,1 secondes et paraître rapide parce qu'elle affiche immédiatement une structure, des placeholders, un retour visuel.
La fluidité ressentie relève autant de la conception d'interface que de la technologie sous-jacente. Un cahier des charges qui exige « des performances natives » sans définir ce que cela signifie pour l'utilisateur ouvre la porte à tous les malentendus. Chiffrez plutôt : temps d'affichage du premier contenu utile, temps de réponse à une action, fluidité du défilement sur une liste de tant d'éléments.
6. Qui va maintenir l'application dans trois ans ?
Compétences internes disponibles, dépendance au prestataire, transmissibilité du code
Question rarement posée dans les consultations, et pourtant décisive.
Si votre équipe interne maîtrise les technologies web, une application construite sur ces bases restera compréhensible et modifiable en interne. Si vous partez sur deux bases de code natives dans des langages que personne chez vous ne pratique, vous êtes durablement dépendant d'un prestataire externe.
Ce n'est pas forcément un problème. C'est un choix, qui doit être conscient et budgété.
Le coût de maintenance annuel comme critère de choix technologique à part entière
Le développement initial, c'est le premier chèque. Ce n'est pas le plus gros sur la durée de vie du produit.
Il faut compter les mises à jour imposées par les évolutions des systèmes d'exploitation, les corrections de bugs, les adaptations aux nouvelles tailles d'écran, les évolutions fonctionnelles, les mises en conformité réglementaires, les renouvellements de certificats et de comptes développeurs.
Sur trois ans, ce cumul dépasse fréquemment le coût de développement initial. Sur deux bases natives, il double presque mécaniquement, puisque chaque correction doit être portée deux fois, testée deux fois, validée deux fois par deux processus de review distincts.
Natif, hybride, PWA : ce que chaque approche engage réellement
Le développement natif
Deux bases de code, deux équipes, deux cycles de validation
Le natif, c'est deux applications. Pas une application déclinée, deux applications distinctes, écrites dans des langages différents, avec des conventions d'interface différentes, soumises à deux processus de validation indépendants.
Concrètement : une fonctionnalité développée d'un côté doit être redéveloppée de l'autre. Un bug corrigé d'un côté existe toujours de l'autre tant qu'on ne l'a pas repris. Une mise en production nécessite deux soumissions, deux délais d'examen, deux risques de rejet.
Les équipes expérimentées organisent ce parallélisme correctement. Cela reste, structurellement, deux fois le travail sur la partie interface.
Les cas où le natif reste incontournable : performance graphique, accès matériel avancé, exigences de sécurité fortes
Il y a des projets où la question ne se pose pas.
Un jeu avec rendu 3D temps réel. Une application de réalité augmentée. Un outil de traitement d'image ou de son en direct. Un dispositif connecté à du matériel spécifique via Bluetooth ou USB. Une application soumise à des exigences de sécurité fortes avec stockage de secrets dans les enclaves matérielles du terminal.
Dans ces contextes, le natif n'est pas une préférence, c'est une nécessité technique. Le reconnaître fait gagner du temps à tout le monde.
Le vrai coût : développement initial, mais surtout doublement de chaque évolution
Le piège budgétaire du natif n'est pas dans le devis initial, il est dans la trajectoire.
Chaque itération, chaque test A/B, chaque ajustement d'interface, chaque correction se paie deux fois. Sur un produit qui évolue peu, l'impact reste contenu. Sur un produit en itération rapide, avec des cycles courts et beaucoup d'expérimentation, la facture cumulée devient très lourde.
Posez la question aux candidats en ces termes : quel est le coût d'ajout d'un écran supplémentaire une fois le projet livré ? La réponse est instructive.
Le développement hybride et cross-platform
Distinguer les approches : WebView embarquée, frameworks à rendu natif, compilation croisée
« Hybride » est un mot valise qui recouvre des réalités techniques très éloignées. Il faut savoir de quoi on parle.
Première famille : une application web encapsulée dans une coquille native, affichée dans un composant navigateur embarqué. Développement rapide, coût contenu, mais rendu et performances qui peuvent trahir l'origine web sur les interfaces exigeantes.
Deuxième famille : les frameworks qui écrivent une fois et produisent de véritables composants d'interface natifs. Le rendu est natif, la logique est mutualisée. Compromis souvent excellent, avec une réserve : la dépendance au framework.
Troisième famille : la compilation vers du code natif à partir d'un langage unique, avec un moteur de rendu propriétaire. Performances élevées, cohérence visuelle totale entre plateformes, au prix d'un écosystème plus spécifique.
Un prestataire qui utilise « hybride » sans préciser laquelle de ces approches il propose mérite une question de clarification. Immédiatement.
Le mythe du « une seule base de code, zéro spécificité » et ce qu'il coûte quand il se fissure
Le discours commercial promet une base unique. La réalité produit toujours un pourcentage de code spécifique à chaque plateforme.
Dix pour cent sur un projet simple. Vingt-cinq, trente pour cent sur un projet qui touche aux fonctions système, aux notifications avancées, aux paiements intégrés, aux comportements en arrière-plan.
Ce pourcentage n'invalide pas l'approche, il faut simplement l'anticiper dans le budget et dans le planning. Les projets qui dérapent sont ceux qui avaient budgété zéro spécificité et qui en découvrent vingt-cinq à mi-parcours.
La dépendance à un écosystème tiers et son cycle de vie
Choisir un framework cross-platform, c'est lier son produit au destin d'un projet open source porté par une entreprise tierce.
La plupart de ces écosystèmes sont solides, soutenus par de grands acteurs, avec des communautés actives. Certains ont pourtant ralenti, changé de direction, ou été abandonnés. L'histoire du développement mobile en compte plusieurs.
Le risque est modéré, mais réel. Il se gère en regardant l'activité du projet, la fréquence des versions, la taille de la communauté, et l'engagement affiché de l'éditeur principal. Ces éléments méritent une ligne dans la grille d'évaluation des propositions.
La Progressive Web App
Pas d'installation, pas de store, pas de validation : ce que cela libère et ce que cela retire
La PWA change complètement la logique de distribution. On accède au service par une URL, exactement comme un site. L'utilisateur peut, s'il le souhaite, l'ajouter à son écran d'accueil, où elle se comporte alors comme une application, en plein écran, avec son icône.
Ce que cela libère : aucune commission sur les transactions, aucun délai de validation, des mises à jour instantanées pour tous les utilisateurs simultanément, aucune friction d'installation, un coût d'entrée quasi nul pour l'utilisateur.
Ce que cela retire : la présence sur les stores, avec la visibilité et la caution de légitimité qui vont avec. Pour certains publics, notamment en B2C grand public, l'absence de fiche store soulève une question de confiance. C'est irrationnel, mais c'est mesurable.
Les limites d'iOS à connaître avant de s'engager
Il faut les nommer clairement plutôt que de les découvrir en cours de projet.
Les notifications exigent l'ajout à l'écran d'accueil, on l'a vu. Le stockage local peut être purgé par le système si l'application n'est pas utilisée pendant une période prolongée, ce qui pose un vrai problème pour les usages hors ligne intensifs. Certaines API matérielles restent indisponibles. Le travail en arrière-plan est fortement restreint.
Ces limites se réduisent au fil des versions du système, mais elles existent aujourd'hui. Un prestataire qui vous vend une PWA sans les mentionner ne vous rend pas service.
L'avantage stratégique souvent ignoré : la PWA est indexable et travaille pour votre référencement
Et voici l'argument que presque aucun cahier des charges ne mentionne, alors qu'il pèse parfois plus lourd que tous les autres réunis.
Une PWA, c'est du web. Ses pages ont des URL. Ces URL sont explorées, indexées, positionnées dans les résultats de recherche. Chaque contenu, chaque fiche, chaque page de service devient une porte d'entrée potentielle depuis un moteur de recherche.
Une application native, elle, est un contenu fermé. Ce qu'elle contient n'existe pas pour les moteurs de recherche. Vous pouvez y publier mille fiches produit détaillées, elles ne généreront aucune visite organique. Zéro.
Pour une organisation dont l'acquisition dépend en partie de la recherche naturelle, cette différence n'est pas un détail technique. C'est une différence de modèle d'acquisition.
Le point aveugle des cahiers des charges : l'articulation avec le site web
Une application native ne génère aucune visibilité organique
Répétons-le, parce que c'est mal intégré dans les décisions.
Le contenu d'une application native est invisible pour les moteurs de recherche. Un utilisateur qui cherche votre service, votre produit, votre réponse à son problème ne tombera jamais sur votre application par une recherche classique. Il tombera sur votre site, sur celui d'un concurrent, ou sur un comparateur.
Une organisation qui investit massivement dans une application native et néglige son site web se coupe de son canal d'acquisition le plus durable. On voit régulièrement des budgets à six chiffres partir dans une application dont l'audience plafonne, pendant que le site vitrine dort sur une architecture technique de 2016.
Ce que le référencement d'application sur les stores permet et ne permet pas
L'optimisation de la fiche store existe, elle a ses techniques, ses spécialistes, ses résultats. Titre, sous-titre, mots-clés, captures d'écran, avis utilisateurs, volume de téléchargements.
Elle a aussi des limites strictes. Le volume de recherche dans un store est très inférieur à celui d'un moteur de recherche généraliste. Les intentions y sont différentes : on cherche une application connue, rarement une réponse à une question. Et la concurrence sur les termes génériques y est féroce, dominée par des acteurs aux budgets d'acquisition considérables.
Compter uniquement sur le référencement store pour construire une audience, c'est se priver de l'essentiel du gisement.
Le scénario hybride le plus rentable : un site performant qui capte, une app qui fidélise
C'est la configuration qui fonctionne le mieux dans la durée, et elle mériterait d'être le point de départ de bien plus de projets.
Le site web, techniquement irréprochable et riche en contenu, capte le trafic de recherche. Il répond aux questions, il présente l'offre, il convertit les premiers contacts. C'est le haut du tunnel.
L'application, elle, sert les utilisateurs déjà acquis, ceux qui reviennent, ceux qui ont un usage récurrent. Elle apporte le confort, la rapidité, les notifications, la personnalisation. C'est l'outil de fidélisation, pas l'outil de conquête.
Formulé ainsi, le budget se répartit tout autrement. Et l'ordre des chantiers change aussi : on consolide d'abord ce qui capte, on développe ensuite ce qui retient.
Deep linking, App Indexing, universal links : les passerelles à prévoir dès le cahier des charges
Si les deux briques coexistent, elles doivent communiquer. Cela se conçoit dès le départ, pas six mois après la mise en ligne.
Les liens profonds permettent qu'un lien reçu par message ouvre directement le bon écran de l'application si elle est installée, et la page web équivalente sinon. Les liens universels garantissent qu'une même URL fonctionne dans les deux contextes, sans page intermédiaire ni choix imposé à l'utilisateur.
Concevoir cette continuité coûte quelques jours au moment de la conception. La rétrofitter sur un existant coûte bien davantage, et le résultat est rarement aussi propre. Inscrivez-la dans le cahier des charges.
Construire un cahier des charges qui laisse le choix technologique ouvert
Écrire des exigences fonctionnelles, pas des solutions techniques
La règle tient en une phrase : décrivez ce que l'utilisateur doit pouvoir faire, dans quelles conditions, avec quelle contrainte de performance. Laissez les candidats proposer comment.
Cette discipline a un bénéfice immédiat. Elle transforme la consultation en comparaison d'approches, au lieu d'une simple comparaison de prix sur une solution imposée. Vous apprenez beaucoup plus sur vos candidats.
Reformuler « il faut une app native » en « l'utilisateur doit pouvoir scanner un code-barres en moins de deux secondes en entrepôt sans réseau »
Regardez la différence entre ces deux formulations.
La première ferme le débat et n'apprend rien à personne. La seconde contient un verbe d'action, une contrainte de temps mesurable, un environnement physique et une contrainte de connectivité. Elle est testable, elle est opposable en recette, et elle laisse toute latitude sur les moyens.
Appliquez ce traitement à chaque exigence du document. C'est fastidieux, cela prend deux ou trois jours de travail sérieux, et cela change la qualité des réponses reçues du tout au tout.
Les rubriques indispensables
Contexte métier et problème résolu
Commencez par là. Quelle situation actuelle pose problème, à qui, combien cela coûte, ce qu'on cherche à améliorer. Un prestataire qui comprend le problème métier proposera des solutions pertinentes. Un prestataire qui ne reçoit qu'une liste de fonctions livrera une liste de fonctions.
Personas et parcours utilisateurs détaillés
Qui sont les utilisateurs, réellement. Leur niveau d'aisance numérique, leur terminal, leur contexte d'utilisation, leur disponibilité mentale au moment où ils ouvrent l'outil. Un technicien avec des gants sous la pluie n'a pas les mêmes besoins d'interface qu'un acheteur assis à son bureau.
Décrivez ensuite les parcours principaux, étape par étape. C'est souvent en écrivant ces parcours qu'on découvre des trous dans le raisonnement initial.
Périmètre fonctionnel priorisé : indispensable, souhaitable, hors périmètre
Trois colonnes, pas deux. La colonne « hors périmètre » est la plus utile de toutes, parce qu'elle protège le projet des dérives et clarifie ce qui ne sera pas fait.
Un cahier des charges où tout est indispensable n'est pas priorisé. Il oblige les prestataires à chiffrer le maximum, et il empêche tout arbitrage budgétaire intelligent en cours de route.
Exigences non fonctionnelles chiffrées : temps de réponse, volumétrie, disponibilité, accessibilité
« Rapide », « robuste », « fiable » ne veulent rien dire dans un document contractuel.
Écrivez plutôt : affichage du premier contenu utile en moins de 1,5 seconde sur une connexion 4G moyenne. Support de 500 utilisateurs simultanés en pointe. Disponibilité de 99,5 % hors fenêtres de maintenance annoncées. Conformité au référentiel d'accessibilité applicable.
Ces chiffres sont testables. Ils deviennent des critères de recette. Sans eux, la recette se transforme en discussion d'appréciation, et l'appréciation, on le sait, penche toujours du côté de celui qui a écrit le code.
Contraintes réglementaires : RGPD, hébergement des données, accessibilité RGAA, secteurs réglementés
Localisation des données, durées de conservation, base légale des traitements, gestion du consentement, droits des personnes. Ces éléments influencent l'architecture, pas seulement la rédaction d'une politique de confidentialité.
Si vous relevez d'un secteur réglementé, santé, finance, secteur public, les exigences spécifiques doivent apparaître explicitement. Hébergement certifié, traçabilité renforcée, conservation des journaux, obligations d'accessibilité contraignantes. Découvrir ces contraintes après le développement, c'est refaire une partie du travail.
Interopérabilité : API existantes, ERP, CRM, systèmes d'authentification
Une application mobile vit rarement seule. Elle dialogue avec un système de gestion, un fichier client, un annuaire d'entreprise, un système de facturation.
Documentez ces interfaces : ce qui existe, ce qui est documenté, ce qui fonctionne réellement, ce qui devra être créé. Cette section est souvent expédiée en trois lignes, et c'est régulièrement de là que viennent les plus gros dépassements. Une API « existante » qui s'avère non documentée et instable transforme un chiffrage en fiction.
Modalités de recette et critères d'acceptation
Comment saura-t-on que c'est fini ? Qui teste, sur quels terminaux, avec quels scénarios, dans quels délais, avec quelles conséquences en cas d'anomalie bloquante ?
Définir ces règles à froid, avant le début du projet, évite les négociations tendues au moment de la livraison, quand chacun défend ses intérêts.
Propriété intellectuelle, accès aux dépôts de code, réversibilité
Point souvent négligé, aux conséquences durables.
À qui appartient le code produit ? Avez-vous un accès permanent aux dépôts, ou seulement une livraison en fin de projet ? Que se passe-t-il si la relation s'arrête ? La documentation technique est-elle contractuellement due, et à quel niveau de détail ?
Un prestataire honnête accepte ces clauses sans difficulté. Une réticence sur ce point est un signal à prendre au sérieux.
La section « architecture proposée » : la laisser aux candidats et la noter
Réservez une section du dossier de réponse à l'argumentation technique. Demandez explicitement aux candidats de justifier leur choix d'approche au regard de vos exigences fonctionnelles, et de présenter les alternatives qu'ils ont écartées avec leurs raisons.
Notez cette section. Pondérez-la sérieusement dans la grille d'évaluation.
Vous obtiendrez ainsi trois ou quatre analyses techniques de votre projet, gratuitement, par des professionnels. C'est probablement la partie la plus instructive de toute la consultation, et elle vous éclairera même sur des aspects auxquels vous n'aviez pas pensé.
Évaluer un prestataire digital sur son argumentaire technologique
Le signal d'alerte : le prestataire qui propose la même technologie à tous ses clients
Consultez les références sur son site. Si tous les projets présentés reposent sur la même technologie, quels que soient les secteurs et les usages, deux hypothèses. Soit il a une spécialisation assumée et cohérente, et il le dira. Soit il vend ce qu'il sait faire, indépendamment du besoin.
La question à poser est simple : « quel a été votre dernier projet dans une autre technologie, et pourquoi ce choix ? » La réponse, ou son absence, est éclairante.
Les questions qui font la différence en soutenance
« Dans quel cas nous déconseilleriez-vous cette approche ? »
Excellente question, parce qu'elle est inconfortable.
Un prestataire compétent répondra précisément : « si votre volumétrie dépasse tel seuil », « si vous ajoutez tel type de fonction », « si votre cible est majoritairement sur tel système ». Il connaît les limites de ce qu'il propose.
Celui qui répond que son approche convient à tous les cas vient de vous apprendre quelque chose d'important.
« Comment évolue le coût de maintenance sur trois ans selon le scénario ? »
Demandez des chiffres, pas des principes. Coût annuel estimé de maintenance corrective, d'adaptation aux évolutions des systèmes, d'hébergement, de renouvellement des comptes développeurs.
Un prestataire qui a de l'expérience a ces ordres de grandeur en tête. Un prestataire qui esquive n'a peut-être jamais accompagné un produit au-delà de la livraison initiale.
« Que se passe-t-il si nous voulons changer de prestataire dans deux ans ? »
Question de réversibilité, posée franchement. La réponse doit couvrir la propriété du code, la qualité de la documentation, la standardité des technologies employées, la transmission des accès et des environnements.
Une réponse gênée révèle une stratégie de verrouillage. Une réponse claire révèle de la confiance dans la qualité de la relation plutôt que dans la dépendance technique.
Vérifier les références sur des contextes d'usage comparables, pas sur des secteurs comparables
Nuance importante et rarement appliquée.
Un prestataire qui a réalisé dix applications dans votre secteur mais toujours des vitrines de consultation n'a pas d'expérience pertinente si votre besoin est un outil de saisie terrain hors ligne. À l'inverse, celui qui a construit un outil de saisie hors ligne pour des contrôleurs techniques automobiles a exactement l'expérience utile pour votre application de relevés en bâtiment.
C'est le contexte d'usage qui compte : hors ligne, temps réel, volumétrie, criticité, profil des utilisateurs. Pas le code NAF.
Ce que dit la structure du devis : forfait, régie, lots, ou tarif au jour homme
Le forfait global sécurise le budget mais rigidifie le périmètre. Chaque évolution devient un avenant, chaque avenant devient une négociation. Il convient aux projets très bien cadrés, rarement aux produits en découverte.
La régie offre de la souplesse et suppose une confiance solide, plus un pilotage interne réel. Sans ce pilotage, elle dérape.
Le découpage en lots avec jalons de validation constitue souvent le meilleur compromis. On engage un premier lot, on évalue le travail livré, on décide de la suite en connaissance de cause. Le risque est borné, la relation se construit progressivement.
Un devis d'une ligne pour un montant global, sans détail par poste, ne permet aucune comparaison sérieuse. Demandez le détail. Systématiquement.
Trois scénarios types et l'arbitrage qui en découle
Application de commande récurrente pour clients professionnels
Des acheteurs qui passent commande plusieurs fois par semaine, depuis leur bureau ou leur véhicule, sur un catalogue de plusieurs milliers de références. Connexion généralement disponible. Besoin de notifications de suivi de commande.
L'usage est récurrent et professionnel : la barrière d'installation est franchissable, parce que l'outil fait partie du quotidien de travail. Mais aucune fonction ne réclame un accès matériel avancé, et la performance graphique n'est pas critique.
La PWA ou une approche cross-platform couvrent très bien ce besoin. Le natif serait un surinvestissement difficile à justifier, sauf exigence particulière du côté de la sécurité ou de l'intégration.
Point d'attention : soigner l'articulation avec le catalogue web, indexable, qui reste le canal d'entrée des nouveaux clients.
Outil de saisie terrain pour techniciens itinérants
Des interventions dans des lieux mal couverts, des photos à prendre, des formulaires à remplir, des signatures à recueillir, une synchronisation au retour au dépôt. Usage quotidien intensif, parc de terminaux souvent maîtrisé par l'entreprise.
Ici, le hors ligne est structurant et non négociable. La fiabilité du stockage local devient le critère numéro un, et c'est précisément le point faible des approches web sur certains systèmes.
Le natif ou un cross-platform à rendu natif s'imposent. Le surcoût est justifié par la criticité de l'usage : un technicien qui perd sa saisie de la journée, c'est un coût métier bien supérieur à l'écart de développement.
La question de l'indexation ne se pose pas, l'outil est interne.
Service de découverte grand public à usage ponctuel
Un service consulté une ou deux fois par an. Recherche d'information, comparaison, prise de contact. Cible large, terminaux variés, aucune fidélité d'usage.
Demander une installation dans ce contexte, c'est perdre l'essentiel de son audience avant même le premier écran. Le coût d'acquisition d'un utilisateur installé serait sans commune mesure avec la valeur d'un usage annuel.
Le web, en PWA soignée, est la seule réponse économiquement rationnelle. Bonus décisif : le contenu est indexé, il génère du trafic de recherche en continu, il travaille pendant que vous dormez.
Une application native sur ce profil d'usage est un investissement à fonds perdus. On en croise régulièrement, et l'analyse des chiffres d'usage six mois après le lancement est souvent douloureuse.
La feuille de route recommandée avant de lancer la consultation
Étape 1 : cadrage des usages et des parcours
Deux à trois semaines de travail interne. Entretiens avec les futurs utilisateurs, observation sur le terrain quand c'est possible, formalisation des parcours principaux. Cette étape ne parle pas de technologie, pas une seule fois.
C'est aussi le moment où l'on découvre parfois que le besoin réel est différent de celui qu'on avait formulé au départ. Cela arrive plus souvent qu'on ne le croit.
Étape 2 : rédaction du cahier des charges fonctionnel
Trois à quatre semaines. Application des rubriques évoquées plus haut. Relecture par un tiers qui n'a pas participé à la rédaction, idéalement quelqu'un qui posera des questions naïves.
Le document final fait généralement entre vingt et cinquante pages selon la complexité. En dessous de dix, il manque des choses. Au-dessus de quatre-vingts, plus personne ne le lit vraiment.
Étape 3 : consultation ouverte sur la solution technique
Trois à cinq candidats maximum, sélectionnés sur des références comparables en contexte d'usage. Un délai de réponse de trois à quatre semaines, avec une session de questions-réponses ouverte à tous à mi-parcours.
Cette session est précieuse. Les questions posées par les candidats révèlent les zones floues de votre cahier des charges, et vous pouvez les clarifier pour tout le monde.
Étape 4 : comparaison des scénarios sur un coût total de possession à trois ans
Construisez un tableau unique : développement initial, maintenance annuelle, hébergement, comptes et licences, coût estimé d'acquisition d'utilisateurs selon le mode de distribution, coût des évolutions prévisibles.
Les classements changent souvent entre la comparaison des devis initiaux et celle des coûts sur trois ans. Parfois radicalement. C'est le vrai chiffre de décision.
Étape 5 : prototype ou version pilote avant engagement complet
Sur un projet significatif, engagez d'abord un périmètre restreint. Un parcours principal, un groupe d'utilisateurs pilotes, quelques semaines d'usage réel.
Ce que vous y apprenez vaut infiniment plus que tous les ateliers de cadrage : les usages réels diffèrent toujours des usages imaginés. Toujours. Et vous évaluez au passage la qualité de travail du prestataire avant d'engager la totalité du budget.
Le surcoût apparent de cette étape est presque systématiquement récupéré sur la suite du projet.
Faire du choix technologique une décision business et non une préférence technique
Natif, hybride, PWA : ce ne sont pas des camps, ce sont des outils. Aucun n'est supérieur dans l'absolu, chacun correspond à des contextes d'usage précis.
La question pertinente n'a jamais été « quelle est la meilleure technologie ». Elle est : compte tenu de nos utilisateurs, de leur contexte, de notre modèle d'acquisition, de nos compétences internes et de notre horizon budgétaire, quelle approche sert le mieux nos objectifs sur trois ans ?
Formulée ainsi, la décision quitte le terrain de la préférence technique pour rejoindre celui de l'arbitrage business. Elle devient discutable en comité de direction, avec des critères que tout le monde comprend.
Le rôle d'un bon prestataire digital n'est pas de vous vendre sa technologie de prédilection. C'est de vous aider à poser les bonnes questions, de vous présenter honnêtement les compromis de chaque scénario, et parfois de vous dire que le projet que vous imaginez n'est pas celui dont vous avez besoin.
Ceux-là existent. Le cahier des charges que vous écrivez est précisément l'outil qui vous permettra de les reconnaître.
