Chercher une agence d'application mobile à Dijon, c'est souvent chercher une réponse à une question encore ouverte : faut-il une application publiée sur les stores, un site mobile, ou un outil interne accessible depuis un navigateur ? Cette section explique comment nous instruisons ces projets par écrit, ce qui fait varier l'effort, et les erreurs qui reviennent le plus souvent sur les projets d'application en Côte-d'Or.
Les trois besoins réels derrière une demande d'application à Dijon
Derrière cette recherche se cachent trois profils très différents. Le premier a un besoin d'usage terrain : une équipe qui saisit des données en déplacement, en entrepôt, sur un chantier ou en tournée, et pour qui l'application sert surtout à continuer de fonctionner quand le réseau ne suit pas. Le deuxième a un besoin de relation client : fidélité, commande récurrente, réservation côté client final. Le troisième, le plus fréquent, a en réalité un besoin web mobile, et découvre en cours de route qu'une application publiée sur les stores lui ajoute un cycle de validation, une charge de suivi et une dépendance à deux plateformes sans rien lui apporter de plus. Trier entre ces trois cas est la première chose que nous faisons, avant même de parler de technologie, parce que la réponse change tout le reste : le périmètre, le calendrier, la façon dont les utilisateurs arrivent. Un prestataire qui répond oui sans avoir posé cette question vend un livrable, pas une réponse. C'est aussi ce qui explique qu'un projet d'application s'arrête parfois en cours de route : le besoin réel était ailleurs, et personne ne l'a formulé assez tôt.
Comment nous instruisons un projet d'application, entièrement par écrit
Notre fonctionnement est intégralement écrit et asynchrone. Vous décrivez votre besoin, nous répondons sous 24 heures ouvrées avec une lecture concrète : ce que nous comprenons du projet, ce qui nous semble hors périmètre, et les questions qui restent ouvertes. Cet échange écrit remplace le cadrage oral habituel, avec un avantage que peu de gens anticipent : tout est tracé. Bien plus tard, quand il faut savoir si le fonctionnement sans réseau faisait partie du périmètre initial, la réponse est dans le fil de discussion, pas dans le souvenir de deux personnes. Le cadrage se fait ensuite en trois temps. D'abord le parcours principal, celui sans lequel l'application n'a aucun intérêt. Ensuite le contenu exact de la première version réellement publiable. Enfin la liste écrite de ce qui est volontairement repoussé : c'est la plus utile des trois, celle qui empêche un projet de gonfler écran après écran jusqu'à ne plus jamais sortir. Nos réalisations publiées (Chouchou Ribeyre, Au Petit Détail, LB Athletic, Mediavocats, Vectosolve) ont toutes été cadrées de cette manière.
Ce qui fait varier l'effort sur une application, et donc le devis
Deux applications qui se ressemblent à l'écran peuvent demander des efforts sans commune mesure. Voici les facteurs qui pèsent le plus, dans l'ordre où nous les examinons. L'existence ou non d'un back-end : si vos données vivent déjà dans un ERP, un logiciel de caisse ou un site, il faut construire et sécuriser une interface d'accès, parfois sur un système ancien qui n'a jamais été pensé pour être interrogé de l'extérieur. La gestion des comptes ensuite : entre une connexion simple et un système de rôles, de droits et de suppression de compte, l'écart est considérable. La sensibilité des données traitées : des informations de santé, de ressources humaines ou de clients finaux imposent des choix de stockage, de journalisation et d'hébergement que des données publiques n'exigent pas. Le paiement, dont les règles diffèrent selon ce que vous vendez et selon la plateforme. Enfin l'accès au matériel du téléphone (localisation continue, Bluetooth, appareil photo, NFC) : chaque autorisation demandée doit être justifiée lors de la revue, et une autorisation de trop se traduit par des refus et des désinstallations. Nous chiffrons uniquement sur devis, une fois ces points clarifiés par écrit.
Quatre erreurs qui font dérailler un projet d'application
Quatre erreurs reviennent presque systématiquement. La première : ne tester que sur le téléphone du dirigeant, récent et bien connecté, alors que les utilisateurs réels ont des appareils plus anciens, des versions de système différentes et une couverture réseau variable dès qu'ils quittent le centre-ville. La deuxième : oublier la revue des plateformes dans le calendrier. Une soumission peut être refusée pour une raison de forme, politique de confidentialité manquante, justification d'autorisation jugée insuffisante, fonctionnalité considérée comme un simple site emballé, et chaque aller-retour décale la mise en ligne d'autant. La troisième : traiter la fiche de la boutique comme une formalité administrative, alors que le titre, le sous-titre, les captures et la description conditionnent le téléchargement autant que l'application elle-même. La quatrième, la plus lourde de conséquences : croire que la publication apporte du trafic. Une application ne se découvre pas seule. Sans site, base clients ou canal d'acquisition qui pousse vers elle, elle reste invisible. Nous demandons donc toujours, avant la moindre ligne de code, comment vous comptez amener les premiers utilisateurs.
Client de Dijon ou de Côte-d'Or : ce que le contexte local change vraiment
La proximité géographique compte moins qu'on ne le dit, puisque tout notre travail se fait par écrit et que nous instruisons un projet de la même façon à Beaune, Chalon-sur-Saône, Auxerre, Nevers ou Besançon. Le contexte local, lui, change la nature des demandes. Le tissu économique de la Côte-d'Or et de la Bourgogne-Franche-Comté, viticulture, industrie, bâtiment, commerce de centre-ville, oriente vers des outils métier plutôt que vers des produits grand public visant un marché national. Quand la population d'utilisateurs est connue d'avance, et souvent interne, les arbitrages deviennent plus sobres : moins d'écrans, moins de personnalisation, plus d'attention aux conditions de terrain. Deux sous-questions reviennent systématiquement. Freelance ou agence : un indépendant convient très bien à une application simple, à condition d'assumer le risque d'indisponibilité et de savoir à l'avance qui reprendrait le code. Collectivité ou structure publique : la contrainte dominante n'est pas technique mais réglementaire, entre accessibilité, sobriété numérique et localisation des données, ce qui oriente souvent vers un site mobile plutôt que vers une application à installer.
