Pour comparer les devis de développement d’applications Bluetooth, fournissez à chaque prestataire les mêmes informations sur l’appareil et le micrologiciel, le parcours de connexion, la liste des téléphones et des systèmes d’exploitation ciblés, ainsi que les tests de recette. Une proposition portant sur un seul appareil utilisé lors d’une session au premier plan n’est pas directement comparable à une proposition qui inclut également les comportements de reprise, l’utilisation en arrière-plan et plusieurs versions de plateforme.
Documentez l’appareil, le protocole et le micrologiciel
Commencez par indiquer le modèle exact de l’appareil et sa révision matérielle. Précisez s’il utilise le Bluetooth Low Energy (BLE), le Bluetooth Classic ou un autre profil spécifié, et partagez la documentation du protocole ou de l’intégration. Pour le BLE, indiquez les UUID des services et des caractéristiques concernés, les comportements de lecture, d’écriture et de notification, ainsi que les exigences de sécurité ou d’association. Pour un SDK fournisseur, précisez sa version, les plateformes prises en charge, les conditions de licence et les instructions de configuration.
Indiquez les versions du micrologiciel comprises dans le périmètre et expliquez comment elles sont identifiées ou mises à jour. Joignez des exemples de charges utiles, les définitions des commandes, les codes d’erreur et toute limitation connue de l’appareil. Si la documentation est incomplète, signalez les éléments inconnus plutôt que de laisser les prestataires formuler des hypothèses différentes. Demandez-leur d’identifier les modifications matérielles ou du micrologiciel nécessaires, séparément des travaux sur l’application.
Cartographiez les flux de connexion et de données
Décrivez le parcours utilisateur, du premier lancement au bon fonctionnement : détection d’un appareil, sélection, appairage ou association, connexion et passage à un état prêt à l’emploi. Dressez ensuite la liste de chaque action de l’application et de chaque réponse de l’appareil, en précisant les données lues, écrites ou envoyées sous forme de notifications. Une simple liste d’écrans ne suffit pas à définir le comportement Bluetooth.
Précisez ce qui doit se passer lorsque l’utilisateur refuse une autorisation, sélectionne le mauvais appareil, laisse le Bluetooth désactivé, se met hors de portée ou ferme puis rouvre l’application. Indiquez les fonctions qui doivent être opérationnelles au premier plan ou en arrière-plan, si l’application doit mémoriser la sélection d’un appareil et quel état ou quelle consigne de reprise l’utilisateur doit voir. Demandez aux prestataires d’identifier les hypothèses relatives au fonctionnement en arrière-plan pour chaque plateforme.
| Exigence à préciser | Éléments justificatifs ou détails à joindre | Comment vérifier dans la proposition |
|---|---|---|
| Appareil et protocole | Modèle, révision matérielle, documentation du protocole, versions du micrologiciel, informations sur le SDK | Confirmez que les combinaisons exactes d’appareils et de micrologiciels prises en charge sont indiquées |
| Appairage et données | Schéma des flux, exemples de commandes et de réponses, comportements de sécurité et d’association | Vérifiez qu’une réponse attendue de l’appareil ou un état d’erreur est défini pour chaque action de l’application |
| Périmètre des plateformes | Modèles de téléphones et versions des systèmes d’exploitation requis pour le lancement | Demandez la liste des combinaisons incluses, exclues et testées sur des appareils physiques |
| Comportement de reprise | Résultat attendu en cas de déconnexion, de perte d’association, de redémarrage de l’application ou de remplacement de l’appareil | Associez chaque cas à une condition de réussite définie et à des preuves de test |
| Remise des livrables | Code source, instructions de compilation, comptes rendus de tests et documents d’intégration requis | Vérifiez que chaque livrable et son responsable sont nommés dans le devis |
Accordez-vous sur les téléphones et les systèmes d’exploitation
Fournissez aux prestataires la liste des plateformes ciblées, en précisant les modèles de téléphones et les versions des systèmes d’exploitation que vos clients ou votre personnel utiliseront. N’incluez la prise en charge des tablettes que si elle est nécessaire. Précisez si l’application est destinée uniquement à Android, uniquement à iOS ou aux deux ; ne supposez pas qu’une base de code partagée implique un comportement Bluetooth identique sur toutes les plateformes.
Demandez au prestataire de préciser si la couche Bluetooth sera native, partagée ou mixte, et d’expliquer comment ce choix sera testé avec votre appareil. Le développement d’applications Android et le développement d’applications iOS sont des options pertinentes lorsque vous définissez le périmètre d’une seule plateforme à la fois. Pour un produit connecté nécessitant des interventions sur les appareils propres à chaque plateforme, le développement d’applications natives compte l’intégration d’appareils et les tests parmi ses domaines d’intervention.
Définissez les tests de déconnexion et de perte d’association
Traitez la reprise de connexion comme un volet explicite des tests de recette, et non comme une attente informelle. Demandez des cas de test couvrant le premier appairage, une déconnexion normale, une perte d’alimentation de l’appareil, la désactivation puis la réactivation du Bluetooth sur le téléphone, le redémarrage de l’application et la suppression ou la perte de l’association. Pour chaque cas, précisez l’état attendu visible par l’utilisateur, si une reconnexion automatique est attendue et l’action que l’utilisateur doit effectuer si la reprise n’a pas lieu. Définissez le délai acceptable pour chaque résultat comme une exigence du projet, au lieu de supposer une valeur.
Une note sur les changements de comportement d’Android 17, datée du 1 octobre 2026, décrit le réappairage Bluetooth autonome après une perte d’association et recommande aux équipes chargées de l’application et du matériel de vérifier les changements d’état d’association et de simuler une perte d’association. Consultez la documentation Android à jour et confirmez qu’elle s’applique aux versions ciblées avant de retenir ce comportement comme exigence de recette.
Demandez des preuves de test précisant l’appareil et son micrologiciel, le téléphone et la version du système d’exploitation, les étapes exécutées, le résultat attendu, le résultat réel et toute limitation connue. Demandez quels tests ont été exécutés sur des appareils physiques et lesquels ont été simulés. Pour une application existante, incluez dans les documents de cadrage l’accès au dépôt de code ou à une version compilée, les problèmes connus à ce jour et les éventuels résultats de tests antérieurs sur les appareils.
Comparez le périmètre des devis et la remise des livrables
Comparez les propositions ligne par ligne. Vérifiez qu’elles couvrent toutes les mêmes variantes d’appareils, les mêmes flux de connexion et de reprise, les mêmes combinaisons de plateformes, les mêmes états de l’interface utilisateur, les mêmes travaux côté serveur si nécessaire et les mêmes cas de test. Demandez à chaque prestataire de dresser la liste des exclusions, des dépendances vis-à-vis des équipes chargées des appareils ou des micrologiciels, des hypothèses concernant l’accès au SDK et de tout élément nécessitant que votre équipe fournisse du matériel ou des identifiants d’accès.
Clarifiez les critères de recette, la manière dont les défauts non résolus des appareils seront consignés, ainsi que le code source, les instructions de compilation, les comptes rendus de tests et les documents techniques qui seront remis. Si la soumission aux boutiques d’applications, les services côté serveur, l’analyse des données ou la maintenance continue sont nécessaires, mentionnez-les explicitement plutôt que de les considérer comme implicites.
Foire aux questions
Dois-je choisir un développement natif ou multiplateforme pour une application Bluetooth ?
Prenez votre décision après avoir documenté le protocole de l’appareil, le comportement requis en arrière-plan et la matrice des plateformes ciblées. Demandez aux prestataires d’expliquer comment la solution qu’ils proposent sera testée sur votre appareil réel pour chaque plateforme, puis comparez le périmètre et les éléments de preuve plutôt que de choisir uniquement selon le nom du framework.
Que faire si le micrologiciel de l’appareil évolue encore ?
Identifiez les versions du micrologiciel actuellement disponibles, celles prévues pour le lancement et qui contrôle les modifications du micrologiciel. Demandez au prestataire de préciser sur quelle version repose le devis et comment les changements apportés aux commandes, à la sécurité ou au comportement de connexion affecteront le périmètre.
Combien d’appareils dois-je fournir pour les tests ?
Demandez au prestataire combien d’unités physiques sont nécessaires pour le plan de test convenu et quelles révisions matérielles ou versions du micrologiciel doivent être représentées. Indiquez le nombre d’unités que vous pouvez mettre à disposition et signalez toute limite avant de comparer les devis.
Pour préparer un cahier des charges de consultation, communiquez les spécifications de l’appareil, la documentation du protocole et du micrologiciel, le nombre d’unités de test, la destination de tout matériel que vous prévoyez d’envoyer, les téléphones et versions des systèmes d’exploitation ciblés, ainsi que les informations sur l’application, l’API ou le dépôt de code existants. Le périmètre des services de développement d’applications de Manboo Studio peut être défini en fonction de ces exigences ; discutez de vos exigences pour définir le périmètre du projet.