G Suite vs MS Office : quelles stratégies adopter pour migrer des macros VBA sur Google AppsScript ?

0

Jeremy et Mohamed, spécialistes des questions de traitements avancés de données pour des grands groupes, nous partagent leur expérience et leur savoir-faire. A travers ce premier article, ils nous font part de leurs méthodologies stratégiques sur la question de la récupération des macros développées sur Excel pour les installer sur Sheets. Bonne lecture.


Un peu de contexte

Beaucoup d’entreprises, petites ou grandes, ont choisi de remplacer l’indétrônable suite bureautique Microsoft Office par celle de Google : G Suite. Ce changement se nomme : l’Out-Of-Office !

Sur le plan individuel, la prise en main de ces nouveaux outils est relativement rapide. Elle nécessite, au mieux, un temps d’adaptation et, au pire, quelques heures de formation. 

En revanche, à l’échelle de l’entreprise, le challenge est tout autre concernant leur mise en place car elle implique une continuité opérationnelle (#migration). En d’autres termes, tous les fichiers existants en cours d’utilisation sur Microsoft Office, doivent pouvoir s’ouvrir et fonctionner correctement sur les outils G Suite sans perturber l’activité de l’entreprise.

Et comme vous l’aurez compris, tous les fichiers ne sont pas compatibles !

En pratique: la grande majorité des fichiers WORD (.docx) et EXCEL (.xlsx) peuvent fonctionner indifféremment sur G Suite. Beaucoup d’autres, ne requièrent qu’une conversion simple et rapide, quasiment transparente pour l’utilisateur.

Dans la suite de cet article, nous nous intéressons au cas pas si particulier des fichiers qui contiennent des macros VBA. Ils sont de loin les plus délicats car nécessairement non compatibles, mais aussi et peut-être surtout car leur existence même pose problème…

Etat des lieux dans l’environnement Office

Au sein d’une entreprise, les macros VBA représentent le plus souvent des petits scripts qui se sont multipliés et enrichis jusqu’à devenir des [mini] programmes, et dans certains cas des applications indispensables pour le métier de l’entreprise.

  • Exemple 1: la macro qui récupère des données de différents logiciels, agrège, filtre et calcule et fournit un reporting sur lequel repose l’analyse de l’activité (eg “reporting financier”, “reporting d’exploitation”)
  • Exemple 2: la macro qui réalise des calculs scientifiques complexes en s’appuyant sur des tables de références et dont le résultat est essentiel pour le chiffrage de prestation

Jusque-là, rien d’anormal dans cet usage. Le problème vient du fait que ces macros sont développées par les équipes métiers elles-même sans que la DSI ne soit impliquée, ce qui implique :

  • que ces macros sont dans l’ombre du shadow IT : non-officielle dans le répertoire applicatif de la société ;
  • une qualité technique plutôt faible car les macros sont développées par des “non programmeurs” et sans véritable cahier des charges ;
  • pas ou peu de maintenance : il arrive parfois que le seul “développeur” en mesure de maintenir une macro ne soit plus dans l’entreprise alors même que celle-ci continue à être utilisée.

En résumé, des fichiers non compatibles avec G-Suite, qui doivent être recréés à partir d’existants mal fichus et dont beaucoup préférerait oublier l’existence.

Etat des lieux côté G Suite

Est-il seulement possible de migrer une macro VBA dans G Suite ?

D’une manière générale, Google offre tout un ensemble d’outils techniques pour automatiser sa suite bureautique. Google AppsScript est l’outil de développement des macros (appelés désormais “script”) de G Suite. Plus qu’un outil, AppsScript est un environnement de programmation intégré dans G Suite qui se distingue de VBA par :

  • un langage de programmation différent : Javascript ;
  • un environnement plus évolué, plus puissant et qui permet plus d’automatisations ; mais en échange il est aussi moins permissif, plus exigeant : il oblige à coder mieux. Tout scripteur devra maîtriser le concept d’API ;
  • enfin, on ne parle plus de macro mais de script…
AppsScript, idéal pour intragir avec Google Sheets

Existe-t-il une stratégie d’actions efficace de reprise des macros VBA ? 

Il n’est pas possible de migrer une macro d’un environnement à un autre. Certes des outils de migration existent mais le résultat, lorsqu’il est opérationnel, est laborieux.

Non, une macro doit être recodée.

Comment procéder alors ?

Tout d’abord, il paraît indispensable d’opérer un audit de l’ensemble des macros VBA :

  • répertorier les cas par un recensement des macros utilisées ;
  • factoriser les besoins similaires
  • prioriser la prise en charge grâce à un processus de validation.

Cet audit peut être réalisé de manière proactive par le biais de sondage (Google Forms par exemple). L’Out-Of-Office, est l’occasion unique de cartographier tous ces développements et d’organiser leur réorganisation. En effet, la reprise d’une macro sera différente selon l’usage qu’il est fait dans l’entreprise.

Par exemple, il arrive très souvent que l’ensemble des comptables, de tous les services et toutes les régions d’une entreprise, utilisent leur propre macro pour réaliser la même action: en générale, le conditionnement dans un tableur d’écritures comptables avant import dans SAP. L’audit permet de mesurer l’ampleur du besoin et d’envisager une solution globale (pas nécessairement sur AppsScript).

A l’inverse, l’arrêt des services Microsoft Office est l’occasion d’identifier les besoins manquants grâce à la mise en place d’un support dédié vers lequel seuls les besoins importants remonteront.

Ensuite, pour être véritablement efficace, tout développement doit être précédé par l’identification d’un sponsor. Qu’il soit technique ou métier, un sponsor facilite la question du budget puisqu’il porte la responsabilité du développement. Son engagement garantit que le besoin est réel et d’actualité. Lui seul permet de passer en mode projet, soit la mise en place des moyens et ressources nécessaires à la réussite de ce développement et ainsi de sortir du Shadow IT.

Enfin, la phase de développement doit largement dépasser la simple reprise. Au minimum il s’agit d’une phase de re-engineering, c’est à dire d’optimisation sur le plan technique et/ou fonctionnel. Mais il peut s’agir de redéfinir intégralement le besoin (souvent ancien, voir obsolète) : c’est à dire repartir de zéro et non de l’existant.

Pour aller plus loin

Les scripts sous G Suite sont plus puissants que les macros VBA classiques, car il est possible de les packager en modules complémentaires (add-on) et de les publier sur la G Suite Marketplace (en mode public ou restreint à l’entreprise).

Cela rend possible leur gouvernance :

  • administration centralisée des accès ;
  • centralisation des besoins et validation des fonctionnalités (problématique de product owner) ;
  • gestion centralisée des mises à jour et correctifs des bugs ;
  • rationalisation des codes sources : plus de copier-coller de code ;
  • création et diffusion d’un catalogue de modules complémentaires.

En espérant que ces premières questions ont pu vous éclairer sur des décisions à prendre, nous vous invitons à nous contacter pour plus de détails et si besoin envisager un accompagnement dans votre aventure Out-Of-Office !


Vous avez un projet autour de G Suite
et vous souhaitez nous solliciter :

formation | développement | paramétrage G Suite | interventions | …


Qui sommes-nous ?

Jeremy ROCHOT
Développeur / Architecte

Mohamed BAHRI
Expert produit / Gestion de projet

Associés depuis 6 ans, Jeremy et Mohamed ont participé à diverses missions de transformation digitale (G Suite et Google Cloud Platform) chez Veolia, Air Liquide, Valeo, Stallergenes, Lafarge-Holcim, Solvay-Rhodia, Valéo, Terega.


Si vous avez trouvé une faute d’orthographe, veuillez nous en informer en sélectionnant le texte en question et en appuyant sur Ctrl + Entrée .

LAISSER UN COMMENTAIRE

S'il vous plaît entrez votre commentaire!
S'il vous plaît entrez votre nom ici

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.