J'ai reçu ce matin un courriel qui cristallise assez bien la grogne des utilisateurs : « Beaucoup de mes partenaires ont tourné le dos au dernier caprice d'Adobe et s'en tiennent aux versions pré-nuageuses de la suite. Du coup, je me demande si vous n'avez pas adopté la même attitude et stoppé purement et simplement la maintenance de vos anciens scripts InDesign. » D'autres fans d'Indiscripts se disent franchement désarçonnés. Migrer vers CC signifie pour eux l'abandon d'utilitaires devenus indispensables au quotidien. (Et, comme pour attiser les frustrations ambiantes, j'avais promis de longue date des correctifs et mises à jour qui n'en finissent plus d'être différés.)

Une clarification s'impose.

• Les produits Indiscripts sont construits sur deux couches : ExtendScript et ScriptUI. La première articule l'interaction du script avec InDesign et fournit donc ses fonctionnalités essentielles (ce que le script fait). La seconde articule l'interaction du script avec l'utilisateur (vous) via ses boîtes de dialogue, boutons, champs de saisie, etc., formant ce que les programmeurs appellent une « interface-utilisateur » (User Interface).

• Depuis InDesign CS4 et jusqu'à aujourd'hui (CC inclus), la couche ExtendScript offre une stabilité inouïe. En d'autres termes, le code principal de nos scripts — Wordalizer, BookBarcode, IndexMatic… — demeure très largement fonctionnel en dépit des infimes ajustements qu'une nouvelle version d'InDesign peut quelquefois requérir. Ceci doit être rappelé haut et fort : l'architecture interne d'InDesign est sans conteste, parmi toutes les applications de la suite Adobe, la plus sophistiquée et la plus aboutie sur le plan de l'extensibilité. Il n'est donc nullement question ici de faire un procès à l'équipe de développement d'InDesign.

• A contrario, l'avènement de Creative Cloud a causé de sérieux dommages à la couche ScriptUI (qui n'est pourtant qu'à la périphérie). À l'origine, ScriptUI était une sorte de passerelle reliant les scripts à l'environnement graphique du système d'exploitation. Les dialogues, boutons, listes déroulantes, ainsi que les actions de l'utilisateur, étaient simplement relayés et prises en charge par le système lui-même. Certes, quelques bugs retors accidentaient cette passerelle, mais les développeurs de scripts avaient encore le docte loisir de les isoler, ou de les contourner, par diverses manœuvres chirurgicales. Mais CC a introduit un changement de paradigme : ScriptUI est dorénavant une passerelle entre nos scripts et un composant propriétaire d'Adobe (Drover), lequel gère maintenant la cosmétique de A à Z.

Et alors ? N'est-ce pas une bonne nouvelle que ScriptUI délivre des interfaces homogènes avec les applications CC, et indépendantes du système d'exploitation ?

• Peut-être, mais il y a un hic : ScriptUI CC ne fonctionne, à ce jour, que « peu ou prou » ! De toute évidence, Adobe ne s'est pas donné pour vocation primordiale de reconduire ses fonctionnalités historiques. C'est ainsi qu'au lancement du Cloud en juin 2013, les auteurs de scripts sont tombés des nues et l'ont fait savoir. Depuis lors — reconnaissons-le — l'équipe d'Adobe a progressivement restauré, ou juste reconnecté, certains rouages disparus. Mais on est encore loin du compte. Beaucoup d'entre nous attendent, entre autres, le retour en grâce de l'objet ScriptUIFont. Et je ne vous parle pas des aléas funestes de la « boucle d'événements ».

• Il m'a été recommandé à maintes reprises de troquer ScriptUI pour une nouvelle technologie plus sexy, comme Flash/Flex. Au vu des derniers virages de la conjoncture, il ne me m'apparaît pas si flagrant que c'eût été un investissement d'avenir ! Mes confrères me disent entêté. Eh bien, je souhaite seulement que le module ScriptUI fonctionne conformément à sa spécification. Cette technologie constitue à mes yeux un minimum syndical pour les développeurs tournés vers les processus objet (le DOM, dans notre jargon). Ainsi, ScriptUI devrait rester l'outil optimal, le chemin le plus court, de ceux qui travaillent essentiellement dans la couche ExtendScript et ne se gargarisent pas de l'idée que « programmer consiste à faire de belles interfaces ».

• J'ajoute enfin que ma politique reste d'offrir, autant que faire se peut, des produits rétro-compatibles (bi-plateformes et cross-versions). Les retours d'utilisateurs témoignent en effet de ce qu'InDesign CS4 est encore à l'œuvre dans de nombreux flux de production ! De ce point de vue, l'urgence d'encapsuler mes produits dans des panneaux HTML5 ne m'apparaît pas avec une évidence impérieuse.

Aussi, pour en revenir à la question titre, voici ma réponse : Indiscripts envisage résolument la mise à niveau de tous ses produits vers CC, sous réserve des dispositions ci-dessus. D'ailleurs, abstraction faite de l'interface, le code sous-jacent est déjà très largement compatible. Tout le problème vient de ce que ScriptUI, lui, n'est pas encore à niveau. Et, vous l'aurez compris, cela ne dépend pas de moi :(

Merci de votre compréhension.