Comment connecter une application mobile à votre système d’information ?

Oui, mais cela demande une couche d’intégration claire. Il faut normaliser les objets métier, les statuts et les règles d’autorité entre les différents systèmes, sinon l’application mobile ne fera que déplacer les incohérences.

Oui. Salesforce peut alimenter l’application mobile en comptes, contacts, opportunités, activités ou dossiers, via ses API. Le point clé est de décider quelles données sont réellement utiles côté mobile et quelles actions doivent remonter vers le CRM.

Oui, à condition de cadrer proprement les flux, les objets et les règles de sécurité. SAP peut servir de source pour des stocks, commandes, interventions, articles ou données de référence, mais la couche mobile doit rester lisible et ne pas exposer toute la complexité du progiciel.

Il faut d’abord vérifier s’il existe un export exploitable, une base intermédiaire, un connecteur, ou une possibilité d’exposer une API métier minimale. L’absence d’API ne bloque pas toujours le projet, mais elle change fortement le coût et le niveau de fiabilité attendu.

Dans la plupart des cas sérieux, oui, au moins sous la forme d’une interface d’échange maîtrisée. Cette interface peut être REST, GraphQL, un webhook, un connecteur ou une couche backend spécifique. Le plus important est de ne pas lier le mobile directement à une logique instable ou mal gouvernée.

Il faut définir quelles données peuvent être modifiées hors ligne, quelle version fait autorité, quand une fusion automatique est possible et quand une validation humaine est nécessaire. Sans ces règles, les conflits sont simplement repoussés après la mise en ligne.

Oui, et c’est même un cas fréquent. Il faut alors relire la base existante, identifier les objets utiles, sécuriser l’interface d’échange et éviter que les règles métier ne soient dupliquées entre le logiciel interne et le mobile.

En pratique, on combine généralement OAuth 2.0, JWT ou OpenID Connect pour l’authentification, TLS pour les flux réseau, des permissions par rôle, de la journalisation et une gestion stricte des secrets techniques. La sécurité utile tient autant à la gouvernance qu’au protocole.

Non. Certaines données doivent remonter immédiatement, d’autres peuvent attendre l’ouverture de l’application, un traitement en arrière-plan ou le retour du réseau. Le bon rythme dépend du métier et de la décision associée.

Oui, si la première architecture sépare correctement l’application mobile, l’API, les règles métier et les connecteurs. Une base bien conçue permet d’ajouter un nouvel ERP, un nouveau back-office ou un nouveau flux sans réécrire tout le mobile.

Le délai dépend surtout de la qualité des interfaces existantes, du niveau de sécurité attendu, du besoin hors ligne et du nombre de règles métier à formaliser. L’intégration elle-même est rarement le seul sujet ; le vrai temps se joue souvent dans le cadrage du SI utile.

Oui, mais il faut alors décider où chaque donnée fait foi. Un compte peut venir du CRM, un stock de l’ERP et un historique d’intervention d’une base interne. Sans source de vérité claire, la mobilité ne fera qu’exposer les contradictions du système.

Très souvent, oui. Cette couche permet de sécuriser les échanges, d’orchestrer les synchronisations, d’unifier les règles métier et d’éviter que l’application mobile dépende directement des spécificités de chaque logiciel.

Le projet devient rationnel quand la ressaisie, les retards, les erreurs terrain ou l’absence de visibilité coûtent déjà plus cher que le cadrage d’une application connectée. Le bon calcul porte moins sur le mobile seul que sur les frictions supprimées dans le SI global.