vendredi 22 janvier 2010

Google Apps, coexistence et intégration au Système d'Information


Comment profiter des dernières opportunités logicielles, en tenant compte de la réalité technique et fonctionnelle du Système d'Information ? Mettre en oeuvre une nouvelle application est une chose, l'intégrer à l'existant en est une autre. Ces problématiques paraîtront d'autant plus complexes que le saut technologique et fonctionnel est important. 








Qu'en est il avec Google Apps ? Comment gérer la coexistence de Google Apps avec le système d'information en place, et son intégration y est elle possible ? Chaque étape d'un projet de bascule pose des problèmes spécifiques. Cet article fait une synthèse des outils qui permettent d'y répondre.

Migrer les données vers Google Apps

Deux types d'outils permettent de basculer les données d'un environnement à l'autre : D'une part les outils bureautiques qui basculent les données personnelles, stockées en local. D'autre part les outils centraux qui permettent aux administrateurs de piloter les campagnes de migration.

Des passerelles spécifiques sont développées et maintenues par Google en fonction des technologies en place : Microsoft Exchange, Lotus Notes, ou d'une manière plus générique le protocole IMAP. Pour répondre à des besoins spécifiques, des API dédiées à la migration rendront possible le développement rapide d'outils sur mesure. Ces API sont entre autres disponibles dans les filières de développements les plus connues, java, .NET, php. 

Au final, le large éventail d'outils mis à disposition par Google permet de mettre en oeuvre un plan de migration sur mesure, adapté au contexte du projet.


Intégrer

Le soucis du détail est important pour favoriser l'adoption d'un nouvel outil. Certaines fonctions apportent leur contribution à une expérience positive: Par exemple un icône reconnaissable sur le bureau, un lien mailto: qui lance GMail, une authentification unique, un carnet d'adresses personnelles à jour, un annuaire à jour, contenant les informations de l'organigramme central, l'historique complet des mails, le classement par libellé à l'image des dossiers...  

De même que pour la migration, Google Apps propose différents outils de synchronisation : on peut par exemple mettre à jour l'annuaire à partir des serveurs LDAP Microsoft Active Directory ou Lotus Domino. Si l'on ne dispose par de serveur LDAP, on pourra mettre à jour ces informations via l'interface standard Google Contact, ou bien par chargement de fichier CSV, ou encore depuis une interface développée spécifiquement...


La coexistence

Une intégration réussie passe souvent par un déploiement progressif. Au minimum, un projet pilote permet de qualifier la solution techniquement et fonctionnellement, de mettre en place les procédures de support si besoin, de préparer le plan de communication et de formation... On doit se préparer, pour une période plus ou moins longue, à gérer la coexistence de deux systèmes de messagerie.

Un premier point est la distribution des mails : Il existe de multiples solutions pour distribuer les mails via l'un ou l'autre des deux système de messagerie, avec ou sans duplication de mail. Ces solutions sont construites en mettant en oeuvre le paramétrages de champs MX sur les domaines et sous domaines, la duplication de mails, les alias de domaine Google Apps. Ces manipulations techniques sont transparentes pour l'utilisateur final qui conserve sont adresse mail habituelle.

Les possibilités d'intégration et de migration rendent la coexistence non seulement possible, mais transparente à l'usage. Il est même possible, pour les adeptes, de continuer à utiliser le mail, les contacts et le calendrier Microsoft Outlook en local, sans vraiment savoir que le coeur du réacteur est géré par Google Apps.


La réversibilité

Les mails représentent un volume de données considérable, mais d'une complexité limitée : Après tout il s'agit d'un message formaté et de ses pièces jointes. Les même API qui permettent la lecture et l'écriture dans Google Apps, peuvent être utilisées pour rappatrier tout ou partie des données. Il en est de même pour les autres données d'annuaire, de contacts, de documents et de sites intranet : Tout est accessible par programmation, via des services documentés et disponibles. 

Le désengagement de Google Apps sera donc toujours possible, et ni plus ni moins compliqué que la bascule intiale : tout dépend de ce que l'on voudra faire des données récupérées. En allant un peu plus loin, un éditeur concurrent pourra développer les connecteurs permettant de basculer les données dans son système, où qu'il soit.


Les coûts

C'est l'un des grand avantage du Cloud : Le fait de ne pas avoir à dimensionner des infrastructures, à commander, installer et monitorer des serveurs, à installer un nouvel applicatif inconnu des équipes d'industrialisation, fait gagner un temps précieux et réduit singulièrement le budget du projet. L'essentiel de la problématique technique du projet est déportée chez le fournisseur. Les équipes techniques internes auront une disponibilité accrue. Elles pourront se consacrer aux cas spécifiques qui ne sont pas adressés par les outils Standards Google Apps.

La facturation en fonction du nombre de comptes mails ne peut être plus simple : Il ne reste plus qu'à bien optimiser ce nombre de comptes pour contrôler les coûts. Les coûts de maintenance seront en forte baisse par rapports aux solutions traditionnelles : plus de patch ou de montée de version à appliquer, un support aux utilisateurs réduit, grâce à une plus grande simplicité applicative, et l'absence de logiciel bureautique.


Le Management du changement

C'est bien le seul aspect du cloud computing qui n'est pas en rupture avec l'existant. La messagerie est un outil critique et utilisé par tous, il faut donc soigneusement organiser et dérouler le plan de communication et de formation du projet. Comme pour tout projet de changement, il faudra veiller d'une part, à ce que la réputation du nouvel outil soit positive, d'autre part à ce qu'aucun utilisateur ne se retrouve un jour seul face à son problème de messagerie.

Il faut reconnaître à Google un véritable savoir faire en matière d'ergonomie des applications. Ne laisser à l'utilisateur final que le strict nécessaire, et décider de supprimer tout ce qui n'est pas indispensable, voilà un modèle en rupture. D'autres suites logicielles ont tendance à accumuler les sous fonctions dans des sous menus qui restent inconnus et inutilisés par 95% des utilisateurs. Ici c'est bien l'expérience de l'utilisateur qui prime sur la somme des fonctions et sous fonctions disponibles. Cette simplicité va faciliter la gestion du changement. 

Nous avons chez Ogys une grande habitude des formations à GMail : Nous constatons que même pour des utilisateurs peu portés sur les nouvelles technologies, le sentiment d'inquiétude disparaît rapidement, en moins d'une heure : C'est le temps maximum qu'il faut pour expliquer l'archivage selon GMail, les conversations, les libellés et les filtres.

En conclusion, 

L'effort nécessaire pour basculer sous Google Apps est étroitement liée à l'existant. Dans un cas simple limité à quelques dizaines de comptes, une bascule peut être gérée en une semaine. Dans le cas d'un déploiement plus vaste, il faudra construire un planning de déploiement sur mesure, probablement progressif, et donc gérer la coexistence des deux mondes. Les possibilités poussées de synchronisation permettent d'envisager des déploiements sur des sous périmètres  : Filiales, salariés en Home Office, postes bureautiques Light ...







Autres articles relatifs à l'intégration de Google Apps