La mise en production des projets data – IA ne doit pas être un obstacle et les conditions de ce passage en production doivent s’adapter en fonction de trois critères majeurs. Mode d’emploi d’une mise en production réussie avec Dominique Poudevigne, VP customer success and implementation EMEA pour Dataiku.
L’ambition des entreprises est le passage en production. Y a-t-il un mode d’emploi ?
À mon sens, l’expression « passage en production » suscite une certaine incompréhension sémantique. Elle laisse entendre que les mêmes modalités de mise en production s’appliquent quelle que soit la nature du projet. Or non. Tous les projets data ne sont pas égaux entre eux.
A lire aussi : AXA nourrit le goût de la data de ses métiers
Entre un simple tableau de bord construit pour l’usage individuel d’un métier et un modèle impactant une chaîne de production, les différences sont considérables. La notion de passage en production s’appliquera donc différemment pour chacun de ces projets.
Il faut donc commencer par classifier les projets ?
En effet. Et cela commence par ces trois questions principales concernant un projet data.
D’abord, à quel degré impacte-t-on un processus métier ? Cela peut aller d’une amélioration ponctuelle à une amélioration systématique, jusqu’à sa refonte complète, voire à l’invention d’un tout nouveau processus. Deuxième question : quel est le niveau de criticité attaché ? Plus simplement, à quel risque s’expose-t-on en cas d’erreur ou d’indisponibilité ? Enfin, troisième facteur à prendre en compte : quel est le niveau d’intégration dans le SI ?
Si l’on reprend l’exemple d’un tableau de bord, cela revient à distinguer un simple rapport généré dans Excel d’un tableau intégré aux outils de productivité, dans un traitement batch ou au cœur d’une application métier. Dans cette dernière déclinaison, on parlera d’in-app analytics.
Ainsi, à chaque projet data, des modalités de mise en production plus ou moins complexes ?
Oui. Selon les caractéristiques du produit data, le niveau d’accompagnement de l’évolution du processus métier sera différent. Il en va de même en ce qui concerne les niveaux de services attendus, très variés selon la criticité, et des éventuels développements d’intégration. L’intégration pourra être simple, voire inexistante, ou au contraire nécessiter des montées de version des applications métiers.
On le constate, la mise en production recouvre des situations très simples comme très exigeantes. Et celles-ci appelleront l’implication ou non des métiers de l’IT, de la production informatique ou de l’analytique.
C’est donc une opportunité pour le métier de gagner en autonomie et pour l’IT de ne pas être un goulet d’étranglement ?
Limiter le périmètre du passage en production aux seuls projets exigeants, c’est se couper d’une grande quantité d’opportunités de créer de la valeur. Aussi, faut-il prévoir d’emblée plusieurs modalités de passage en production.
Des projets simples, non critiques, peuvent par exemple être mis en production en autonomie par les métiers sur une infrastructure placée sous leur responsabilité. Les processus critiques ou très impactants seront, quant à eux, pris en charge par l’IT.
Quels peuvent être les bénéfices pour les métiers avec une telle approche ?
Cela tient à la nature même des projets data. Ils sont bien souvent exploratoires, fondés sur une connaissance fine du métier et des données.
Ces projets peuvent, grâce à cette approche, naître au plus près des métiers, développés par les métiers eux-mêmes, avec ou sans l’intervention de data scientists en central. C’est le grand bénéfice des outils no-code ou low-code. Dans un second temps, les projets pourront éventuellement être transférés à des fonctions IT pour être industrialisés.
Cela explique que l’on observe une grande variété de cycles de vie de ces projets. Dataiku, comme plateforme accessible à tous, participe beaucoup à cette fécondité. Encore faut-il rompre avec le schéma monolithique, désormais assez ancien, dans lequel le métier exprime ses besoins et l’informatique développe l’applicatif.
A lire aussi : Retour sur le Workshop « Projets Data/IA : quelles sont les bonnes pratiques des DSI pour industrialiser ? »
Pour se transformer, une organisation devrait donc, simultanément, ouvrir la voie à des initiatives simples et à d’autres, plus profondes ?
Même s’il ne faut pas se couper d’une masse de projets simples et utiles, la création de valeur à l’échelle ne se fait qu’à travers des changements de processus métiers industriels. Et dans ce cas, c’est l’affaire de l’IT, son métier, sa mission, qu’elle gère très bien pour les applications métiers depuis toujours. L’informatique doit prendre en responsabilité la mise en production de projets data critiques.
Comment peut-elle tenir ce rôle ?
On ne peut opérer que ce qu’on comprend. Dès lors, la solution est que l’IT dispose du savoir-faire nécessaire pour comprendre ces applications. Cela suppose, entre autres, qu’elle construise des équipes pour se positionner comme un fournisseur de projets data.
La finalité n’est pas que la DSI s’empare d’un monopole sur ces projets. La gouvernance doit veiller à préserver le foisonnement et l’autonomie des métiers. Mais grâce à ses compétences, ses data engineers et data scientists, l’IT peut assumer une responsabilité d’appropriation des projets critiques et d’urbanisation du portefeuille.
Comment voyez-vous les prochaines années en ce qui concerne la conduite des transformations data ?
Dans un monde rêvé, les projets data peuvent avoir des vies très différentes, favorisant l’innovation au plus près des métiers, et sur une plateforme commune pour éviter les ruptures et les réécritures.
Les modalités de mise en production sont souples. Elles permettent de saisir toutes les opportunités, des plus modestes aux plus ambitieuses. Enfin, l’IT développe des projets data et prend en toute confiance la responsabilité des projets critiques. Mais elle apporte également une force d’urbanisation et de réutilisation au service de tous.