Une application événementielle a une contrainte que presque aucun autre produit ne connaît : elle doit fonctionner parfaitement pendant 2 ou 3 jours, dans un bâtiment conçu pour bloquer les ondes, pour des milliers de personnes qui l'ouvrent toutes au même moment. Tout le reste en découle. Voici 3 idées qui survivent à ces conditions — et pourquoi chacune est plus difficile qu'elle n'en a l'air.

Commencez par la contrainte qui décide de tout : la connectivité

Un hall d'exposition, c'est du béton, de l'acier et du verre, rempli de gens dont les téléphones se disputent les mêmes antennes. Le Wi-Fi est saturé dès le milieu de matinée. Toute fonctionnalité qui suppose une requête en direct échouera précisément quand la salle est pleine — c'est-à-dire au moment où l'application est jugée.

Les recommandations d'architecture d'Android sont sans ambiguïté : "there must be at least one data source that does not need network access to perform its most critical tasks", et une base locale est "the recommended source of truth for providing offline-first support". L'application doit "present users with local data immediately instead of waiting for the first network call to complete or fail" (Android Developers, 2026).

En résumé : concevez en offline-first, sinon les 3 idées ci-dessous seront parfaites en démonstration au bureau et s'effondreront sur le salon.

Idée 1 — Un programme en direct qui survit à un changement d'horaire

L'écran le plus consulté d'un événement, c'est « qu'est-ce qui se passe, où, et quand ». C'est aussi celui qui bouge : un intervenant en retard, une salle échangée, une session annulée 20 minutes avant. Un programme imprimé ne sait pas faire cela — c'est précisément la raison d'être de l'application.

La difficulté, c'est que la mise à jour doit atteindre un appareil parfois hors ligne. Le schéma qui fonctionne : un programme en cache affiché depuis le stockage local, un petit delta synchronisé dès que la connexion revient, et un horodatage visible pour que le visiteur sache si sa copie est fraîche. La différence essentielle avec une application classique, c'est que « périmé mais honnête » vaut mieux que « vide mais exact ».

Idée 2 — Une capture de contacts que les exposants paieront vraiment

Pour un exposant, l'événement se résume à un indicateur : les conversations qualifiées. Le scan de badge transforme une pile de cartes de visite en liste structurée, et c'est la fonctionnalité la plus susceptible de faire de l'application une ligne de revenu plutôt qu'une ligne de coût.

La réalité technique, c'est que le scan se fait dans les pires conditions : mauvaise lumière, badge retourné, file d'attente qui se forme. Le scan doit donc être local et instantané, l'enregistrement écrit d'abord sur l'appareil puis synchronisé, et un scan raté doit proposer une saisie manuelle plutôt qu'un indicateur de chargement. Ajoutez un champ de note : ce qui qualifie un contact ne figure presque jamais sur le badge.

Idée 3 — Une orientation qui fonctionne là où le GPS ne fonctionne pas

Le GPS est peu fiable en intérieur : un plan d'événement ne peut pas reposer sur un point bleu. Ce qui marche est plus terne et bien moins cher : un plan zoomable embarqué dans l'application, des stands cherchables par nom et par numéro, et un itinéraire décrit comme les gens indiquent réellement le chemin — « Hall 2, allée C, en face du point café ».

Le plus important : le visiteur n'a pas besoin d'une précision au centimètre. Il a besoin de trouver le stand C14 sans réseau, et de l'avoir mis en favori le matin même quand il avait encore le Wi-Fi de l'hôtel.

Ce que tout le monde oublie : l'application survit à l'événement

Une application événementielle est utilisée intensément pendant 3 jours, puis dort sur le téléphone. Cela a deux conséquences qu'il faut anticiper. La première : la fiche store et l'application ne doivent pas se périmer entre deux éditions — Google Play impose de suivre les niveaux d'API cibles pour rester visible, et les applications sous le niveau requis "stop being discoverable to all Google Play users whose devices run Android OS versions newer than your app's target API level" (Google Play Console Help, 2026). Une application laissée en l'état pendant un an cesse discrètement d'apparaître sur les appareils récents.

La seconde : le moment le plus utile, c'est la semaine d'après. Les contacts scannés, les sessions réellement suivies, les stands mis en favori — c'est la matière de l'édition suivante, et la raison de garder un seul produit plutôt que de commander une nouvelle application chaque année.

Vous préparez une application événementielle et souhaitez intégrer les contraintes hors ligne dès la conception ? Réservez un appel de 30 minutes.