Applications mobiles — natives et cross-platform pour les PME.

Une décision de stack est à long terme — les applications mobiles vivent trois a cinq ans, souvent plus. Nous choisissons par projet consciemment et de maniere justifiee, plutôt que d'imposer une préférence maison.

.NET MAUI · pour stacks proches de Microsoft

Framework cross-platform de Microsoft, successeur de Xamarin Forms. Une codebase C# couvre iOS, Android, macOS et Windows. Pertinent si vous utilisez déjà Dynamics 365, Power Platform ou un stack backend .NET — les bibliotheques d'authentification (MSAL), la connexion Dataverse et la Microsoft Identity Story sont ici les plus matures. Notre defaut pour les applications de terrain B2B avec intégration Microsoft.

React Native · pour projets cross-platform larges

Framework base JavaScript/TypeScript de Meta, avec le plus grand ecosysteme de composants open source. Pertinent quand l'équipe web pense en TypeScript et que le partage de code entre web et mobile est utile (par exemple logique de validation, clients API). Nous utilisons typiquement avec Expo, qui simplifie le tooling de build et les pipelines de mise à jour.

Swift / Kotlin natifs · quand la tâche l'exigé

Quand des fonctions AR (ARKit / ARCore), inference CoreML sur l'appareil, traitement audio/video professionnel ou animations UI au pixel près sont demandés, il n'y a pas d'alternative au développement natif. SwiftUI pour iOS, Jetpack Compose pour Android. Ici nous livrons par plateforme — effort plus élevé, mais profondeur de plateforme maximale.

Stockage de données · SQLite et moteurs de sync

Les applications hors ligne ont besoin d'un stockage de données local, typiquement SQLite — directement ou via Realm ou WatermelonDB. Nous choisissons les stratégies de sync (last-write-wins, operational transforms, CRDT) selon la tolerance aux conflits. Pour les applications basees sur D365/Dataverse, nous utilisons le mecanisme de sync Microsoft Field Service où en construisons un propre si nécessaire.

Identité · OAuth 2.0 avec Microsoft Entra ID

L'authentification passe par OAuth 2.0 avec PKCE, les tokens sont stockes dans le Secure Storage de la plateforme (Keychain sur iOS, Keystore sur Android). Pour l'intégration Microsoft, nous utilisons MSAL (Microsoft Authentication Library), qui apporte Conditional Access, MFA et Single Sign-On out of the box.

Si vous etes déjà dans le stack Microsoft, cela simplifie nettement une stratégie d'application mobile. Quatre points d'ancrage concrets ou nous intégrons profondement :

Dynamics 365 Field Service — comme backend. Ordres de service, dispatching, données d'actifs, rapports de service : tout est présent dans le modèle de données Field Service. Nous construisons l'application mobile soit sur le Microsoft Field Service Mobile SDK soit directement contre l'API web Dataverse, selon la personnalisation nécessaire.

Dynamics 365 Sales — comme backend. Applications terrain avec capture de leads, vue des comptes, préparation aux rendez-vous. Reflet hors ligne des comptes, contacts et opportunités.

Microsoft Entra ID — comme fournisseur d'identité. Single Sign-On dans l'application via MSAL, Conditional Access (par exemple « autorisé uniquement depuis la France »), MFA via Authenticator. Pas de login utilisateur propre, pas de gestion séparée des mots de passe.

Microsoft Intune — comme MDM et canal de distribution. Pour les applications internes, nous distribuons via Intune Company Portal plutôt que via App Store / Play Store. Plus politiques de conformité (chiffrement de l'appareil, obligation PIN, Remote Wipe). Pertinent si l'application ne doit pas être publique ou si un pilotage d'appareils à l'echelle de l'entreprise est demandé.