jeudi 19 janvier 2012

Google Apps est-il trop simple pour les Grands Comptes?

L'autre élément important de l'annonce concernant l'implémentation des Google Apps dans l'entreprise BBVA est la taille du compte. Avec plus de 110 000 utilisateurs répartis à travers plus de 30 pays, Banco Bilbao Vizcaya Argentaria se caractérise clairement comme un Grand Compte. Ceux-là même que les détracteurs de Google Apps considéraient comme insensibles à ses avantages... Les Grands Comptes seraient, par nature, "trop exigeants pour se satisfaire des fonctionnalités standards de Google Apps" (sic!). A ceux-là, on pourra faire valoir que simple ne veut pas dire simpliste, de la même manière que complexe ne veut pas dire fonctionnel... Google Apps dispose d'un grand nombre d'options d'administration et de paramétrage qui permettent de l'adapter à des situations variées (multi-domaines, multi-plateformes, multiple connexions simultanées, etc.). Certes, pour restreindre l'accès d'un utilisateur à une fonctionnalité, il faut, dans Google Apps, l'avoir préalablement assigné à un groupe spécifique : on ne peut pas, comme dans d'autres systèmes, [passer 1h30 à] le faire directement... S'agit-il d'une limitation majeure?

En pratique, quelles options manquent à Google Apps? Question subsidiaire: ces options existent-elles dans le Marketplace? Si non, ne peuvent-elles pas être développées en exploitant les API des Google Apps? En admettant que, passé ce filtre, il reste des fonctionnalités présentes dans les autres systèmes, quelle est la probabilité que leur absence soit réellement rédhibitoire? A partir d'un certain niveau, je ne pense pas pouvoir être taxé de mauvaise foi lorsque j'incite les décideurs à s'interroger de manière pragmatique concernant l'utilité de certains paramètres spécifiques... Après tout, il s'agit ici d'applications de messagerie et de bureautique, dont l'usage, pour important qu'il soit, ne diffère que marginalement d'une entreprise à une autre. Contrairement à un ERP, par exemple, et malgré les gains de productivité substantiels qu'apportent les solutions modernes (comme Google Apps, par exemple...), il y a relativement peu d'avantages compétitifs à obtenir du paramétrage de son traitement de texte... Mais quitte à aller dans cette direction, de la course aux fonctionnalités, alors, on pourra retourner la question vis-à-vis des ténors de la messagerie d'entreprise classique: disposez-vous de toutes les fonctionnalités présentes dans Google Apps et son marketplace? Et surtout : pouvez-vous être "customisé" et intégré au moyen d'API ouvertes? Car, dans le domaine de l'inter-opérabilité et de l'évolutivité, Google, grâce à son modèle basé sur le cloud, les standards ouverts (HTML, IMAP, XML, etc.), les API et les Google Apps Script, n'a pas de leçon à recevoir.  J'entends alors venir la réponse: "ah oui, mais alors ça devient beaucoup trop complexe s'il faut aller chercher des fonctionnalités dans des solutions externes...". Je pourrais épiloguer sur le revirement de la critique, la retourner en rappelant que, dans le cas de Google Apps, un éventuel surplus de complexité en amont, durant la phase de mise en place, se traduit par une grande simplicité à l'administration et à l'utilisation au contraire de ses principaux concurrents... Mais ces divergences qui compliquent la comparaison tiennent au fait que, fondamentalement, Google Apps et son modèle SaaS changent les règles du jeu de l'informatique d'entreprise. Entre le tout-intégré propriétaire et le tout-open source, Google propose une solution intermédiaire qui tente de limiter la part des contraintes techniques dans la réflexion concernant le schéma des systèmes d'information. En d'autres termes, la décision concernant la solution à mettre en place ne dépend plus des compétences disponibles dans mon département informatique. Je peux donc accorder plus d'importance aux besoins de mes utilisateurs. Et, de fait, en termes de messagerie et de bureautique, les besoins d'une petite entreprise et ceux d'une grande varient relativement peu. D'où la logique de proposer un socle applicatif unique (Messagerie, bureautique, calendriers, sites, chat pour tout le monde, par défaut), évolutif (pourquoi devoir attendre 3 ans pour accéder aux nouvelles fonctionnalités?) et scalable (même tarif pour chaque utilisateur additionnel). La complexification additionnelle est facultative et ciblée: je n'installe que les fonctionnalités qui me manquent. On est loin du modèle classique selon lequel: d'abord je vois les outils que connaissent mes administrateurs, ensuite, je bride immédiatement mes besoins pour pouvoir m'insérer dans le "package" qui convient à ma situation actuelle chez l'éditeur que mon département informatique a choisi (sachant déjà que si, de PME je rentre un jour dans les critères du Grand Compte, je serai "incité" à migrer vers le package supérieur de la solution) et enfin, je désactive toutes les fonctionnalités qui ne me concernent pas...  Soit, d'une certaine manière, Google Apps fait perdre à l'entreprise un semblant de contrôle sur son infrastructure informatique. Mais que vaut cette impression de contrôle face à la soumission vis-à-vis des formats propriétaires et des montées de version quasi-obligatoires et systématiquement payantes? À quoi sert le contrôle lorsqu'on est asservi aux calendriers des patches de l'éditeur et aux vicissitudes des déploiements? Pour être honnête, il faudra remarquer que le Marketplace, au-delà des innombrables fonctionnalités qu'il apporte, pose un problème flagrant aux entreprises, celui de la confiance vis-à-vis d'entreprises-tierces, dont le code-source des applications n'est pas toujours auditable. Il est tentant d'évacuer cette problématique (légitime au demeurant) avec une pirouette en rappelant que si les départements informatiques s'astreignaient à analyser le code de toutes les applications qu'ils installaient, alors Windows serait inexistant dans l'entreprise... Mais Google Apps propose une alternative viable pour les grandes entreprises qui ont la capacité et la nécessité de contrôler les fonctionnalités qui viennent se greffer à leur messagerie et à leurs outils collaboratifs: les développer elles-mêmes (ou les faire développer par des VAR...) grâce aux API. Ne subsistera alors que la question de la confiance vis-à-vis de Google... Mais cela fera l'objet d'un prochain post! Alors, finalement, qu'est-ce qu'il manque à Google Apps pour satisfaire les Grands Comptes?

2 commentaires:

  1. Qu'en est-il d'Active Directory?

    RépondreSupprimer
  2. Google Apps est compatible LDAP et dispose de nombreuses options pour le user provisionning, du plus manuel au plus intégré (notamment, grâce aux API).

    RépondreSupprimer