Un SI pour des tablettes (tactiles)

Nos DSI pensaient avoir passé un cap en mettant en place des infrastructures de site web client, boutique en ligne, support... Ca a été difficile, notamment pour rendre disponible sur des applications Internet des services de coeur de SI, qui n'avaient pas du tout été conçus dans cette logique, mais au moins on espérait en avoir fini avec les remises en cause.

Et bien non: les tablettes tactiles arrivent, iPad, tablettes Android, etc., y compris en B2B, et elles vont changer certains des métiers, dont la vente et la distribution. Et comme les applications Internet, elles vont poser de nouvelles difficultés en nécessitant un accès selon de nouvelles modalités à des services parfois (souvent) profondément enfouis dans nos systèmes d'information.

Pourquoi?

Partons d'une autre question: Pourquoi les applications iPhone sont-elle majoritairement agréables à utiliser et ont-elles contribué notablement au succès de ces smartphones?

Si je peux avancer une réponse, ce serait parce qu'elles partagent une charte ergonomique stricte et qu'elles sont construite autour de certains modes d'interaction. Ces modes d'interaction sont intuitifs, mais limités, et les applications sont conçues autour de cette limite. Elles sont également conçues autour des cas d'utilisation spécifiques les plus courants: les use cases d'un smartphone sont différents de ceux d'un PC. On va par exemple utiliser un PC pour réserver un billet d'avion, alors que le smartphone va permettre de s'enquérir des horaires, des retards et de s'enregistrer.

La même dichotomie se retrouve sur les tablettes tactiles vs les applications pour PC, même sur des applications d'entreprise. Imaginons un système de vente, permettant de réaliser une souscription de téléphonie mobile, un upgrade de forfait, un changement de mobile... Le cas d'usage de l'application sur PC est celui d'un opérateur en centre d'appel ou en agence, qui a déjà réalisé le dialogue avec son client et passe à la phase administrative, assis à son poste, alors que le client attend. La phase intense d'échange avec le client est plus ou moins terminée, les choix sont faits.

La même application sur tablette aura une autre orientation: elle va pouvoir être utilisée dès le début de la vente, alors que les choix ne sont pas réalisés. Le vendeur est en proximité physique avec le client, il dialogue avec lui et la tablette est une aide pour ce dialogue, y compris pour le client lui-même qui la voit et interagit avec. Le vendeur peut comparer des terminaux, tester la couverture, montrer des options, choisir des offres... Il n'est pas concentré sur son interaction avec son ordinateur, mais sur celle avec son client.

Du coup, il apparaît que l'application qui justifie d'introduire une tablette tactile en distribution ne peut pas être un simple portage technique, mais demande une réécriture avec une logique d'interaction différente. Reformater les écrans d'une application Web ou d'un portail donnant accès à plusieurs applications conçues pour un PC ne suffit pas. Il faut tout repenser en partant des cas d'utilisation les plus importants, en utilisant la grammaire d'interactions de la tablette et en veillant à ne pas détourner l'utilisateur du dialogue avec son client. Ceci implique alors d'accéder aux données et aux services du système d'information d'une manière différente des application traditionnelles, parce que la logique différente de l'application tablette et les contraintes techniques de la tablette impliquent des services et modalités d'accès nouveaux.

Alors, que faire?

Nous pouvons nous inspirer des démarches mises en oeuvre pour créer des applications Internet. On considère les applications Internet comme mouvantes, multiples, parfois jetables, parfois même non issues de l'entreprise mais réalisées par des tiers. Elles doivent pouvoir être réalisées rapidement avec une expertise spécifique, mais sans devoir à chaque fois affronter la complexité du système d'information et sa dette technique.

Pour ce faire, on mettait en place des couches de services spécifiques, isolant cette galaxie d'applications légères et agiles de la complexité du coeur de système d'information. Je propose de suivre une même démarche pour les applications tablettes, en mettant en place une couche de services adaptés à leurs besoins spécifiques, intégrant des services métiers, et peut-être des services techniques partagés.

En plus des cas d'utilisation spécifiques, quelles contraintes techniques nouvelles? Nous pouvons citer:

• des protocoles légers (REST / JSON par exemple), parce que la bande passante et la capacité de traitement du terminal "tablette" sont plus limitées que sur un PC;
• un écran = un service, parce que la fluidité de l'interaction est primordiale, et que la capacité du terminal est limitée;
• des données simples, parce que l'utilisateur doit rapidement s'y retrouver et que le terminal tablette ne doit pas avoir à réaliser de conversion de données complexes (pas de modèle pivot trop riche!).

Comment créer cette couche de service?

Ne pas la créer: la faire émerger. S'inspirer de l'excellente session de l'USI 2009 de mes camarades Benoît Guillou et Dominique Jocal. L'essence est d'utiliser deux patterns de définition de service:

• au départ, un service est créé pour une application, sans préoccupation de réutilisation. Il est défini par un contrat entre un client et un fournisseur, qui repose sur sa signature et le cas d'utilisation de ce client. On a un pattern "consumer contract", ou "contrat client", où on ne se préoccupe pas de réutilisation, seulement d'adéquation avec un besoin. On respecte néanmoins les bonnes pratiques d'implémentation des services (nommage, granularité, gestion d'états...) et de développement;
• lorsque des services similaires sont nécessaires pour plusieurs clients (au moins trois!), on peut envisager une mutualisation et mettre en place un pattern "consumer-driven contract". Le contrat de service lie un fournisseur et plusieurs clients. Il repose sur la signature de service et la somme des cas d'utilisation par les clients.

Pourquoi ces patterns? Ils rendent les services facilement testables, et transparents d'utilisation. Le service respecte le contrat s'il passe une somme de tests d'utilisation. On favorise ainsi une approche de développement et de design reposant sur les tests, cruciale pour sécuriser un service qui doit être d'autant plus fiable qu'il est utilisé en plusieurs endroits, et donc susceptible de générer plus de perturbations s'il dysfonctionne.

En synthèse?

Les tablettes arrivent, préparons-nous à en tirer partie, pour la satisfaction de nos clients et de nos salariés. Elles nous offrent l'occasion de tirer partie des enseignements collectés sur les applications Internet pour accélérer le développement d'applications utiles, performantes et agréables. Elles vont enfin nous permettre de construire des infrastructures SOA pragmatiques, dans un modèle adaptable (possibilité de réagir rapidement par rapport aux besoins nouveaux) plutôt qu'adapté (couvrant parfaitement un besoin - réel ou théorique - tel que compris à un instant donné). Ne nous en privons pas!