L’IA chez ARCAD Software : une révolution maîtrisée

Philippe Magne – Bienvenue à tous pour cette petite interview flash pour faire le point sur l’IA et découvrir quelle est la vision d’ARCAD Software par rapport à cette révolution qu’on est en train de vivre qui est absolument majeure et qui évidemment va avoir un impact sur notre entreprise à la fois sur l’aspect interne et externe. Ce que je vous propose, c’est de tout simplement partager avec vous à la fois notre expérience existante, les développements qu’on a fait dans ce domaine, et notre vision du futur par rapport à cette révolution.
Je suis en présence de notre VPN R&D, Marc Dallas. Alors Marc, on va commencer par une première question toute simple, c’est quel usage ton équipe fait de l’IA à ce stade, à quel stade vous en êtes et quelles sont les difficultés que vous avez potentiellement rencontrées dans cet usage ?

Marc Dallas – Je vais revenir un tout petit peu sur l’arrivée de l’IA et comment nous on l’a vécue et comment les collaborateurs du service l’ont vécue. L’émergence de l’IA est arrivée très rapidement de façon très subite en tout cas et notamment auprès du grand public.
Et toute la communication qui a été faite autour de l’IA et de l’utilisation de l’IA dans le domaine professionnel a été extrêmement soudaine. Donc, je ne vous cacherai pas qu’effectivement, ça a généré beaucoup de peur, beaucoup d’appréhension. Il y a eu une phase de stupeur au départ, une phase d’incompréhension et une phase de déni face à ces outils.
Il a fallu travailler en interne de façon très précise, un pour démystifier l’IA, c’est-à-dire comprendre les mécanismes de fonctionnement. C’est des techniciens chez nous, donc on a besoin de comprendre comment ça fonctionne et de savoir jusqu’où on peut aller, quel est le type de remplacement que ça peut faire. Il a fallu retravailler sur ces mécanismes, faire comprendre, avoir toute une campagne interne de conférences qui allait nous expliquer. On a fait intervenir des gens qui nous ont expliqué ce que c’était l’IA, comment ça se montait, et quels étaient les types d’utilisation, pour que les gens, à un moment donné, mesurent qu’en fait l’IA n’était qu’un outil, un outil certes ultra puissant, mais un outil. Et qu’ils puissent aussi faire la part des choses sur la plus-value qu’ils apportaient eux-mêmes en tant que développeurs expérimentés.

P.M. – Ils n’allaient pas les remplacer, mais ils faisaient à l’inverse quelque chose qui allait considérablement augmenter leur productivité.

M.D. – Tout à fait, les aider dans leur quotidien, et notamment sur des tâches où ils se sont aperçus eux-mêmes qu’ils n’avaient plus de plus-value et donc de se concentrer sur l’intelligence qu’ils pouvaient apporter à l’entreprise et dans leur quotidien. Et ça, moi j’estime que ça a été extrêmement rapide chez nous, parce qu’il a fallu un trimestre. Dans d’autres sociétés, c’est beaucoup plus long que ça. Aujourd’hui, en moins d’un an, l’usage de l’IA s’est généralisé dans tous les secteurs. Dans l’utilisation même à ce jour, dans la production de codes, l’explication de codes, la production d’algorithmes, de choses comme ça, mais aussi dans les tâches administratives, rédaction de documentation technique, tout en conservant bien cet esprit critique quant au résultat de l’IA. Donc bien sûr que tout le monde relie, tout le monde valide, et c’est nécessaire aujourd’hui de pouvoir apporter et exercer son esprit critique quant au résultat de l’IA.
Mais aujourd’hui c’est intégré. Quasiment l’ensemble des collaborateurs ont accès soit à des IA gratuites, soit à des IA payantes aujourd’hui intégrées dans nos outils de bureautique. Mais il n’y a plus cette méfiance par rapport à l’IA. Je pense qu’il y a vraiment eu un retournement de situation. Il reste encore quelques exceptions, mais ça on va le travailler au fur et à mesure. Mais cette phase de peur et de stupeur, elle est passée aujourd’hui. Sur le code lui-même, et je reviendrai là-dessus, on s’aperçoit qu’il y a certains défauts.
C’est-à-dire que les IA ont l’habitude de générer du code toujours le même et de transporter à la fois parfois des bugs, des hallucinations liées à ça. C’est pour ça qu’il y a une nécessité de re-regarder. Et il y a une autre problématique, mais on est équipé pour ça, c’est que ce code peut parfois contenir des vulnérabilités.
Alors nous, on est équipé en interne pour le contrôle de nos vulnérabilités pendant les nightly builds, mais ce sont des points importants aujourd’hui qu’on a détectés, c’est que ce code généré potentiellement peut impacter la sécurité du code et qu’il faut être extrêmement vigilant quant à cette utilisation.
Il faut être focalisé sur la notion de vulnérabilité. Les processus de contrôle de vulnérabilité du code ont dû être renforcés. Ils ont dû être renforcés chez nous, mais ailleurs aussi. L’ensemble des interlocuteurs ont vu l’augmentation significative des probabilités de plus d’utilisation de l’IA pour la génération du code.

P.M. – D’ailleurs, nous on le voit, il y a une forte poussée de la demande autour de notre produit CodeChecker, qui est là pour contrôler la vulnérabilité du code source IBM i. C’est évident que l’origine de cette forte poussée est liée à cette préoccupation. Donc là on a un cap qui est passé puisque effectivement il y a eu toute une période de temps où les augures disaient il n’y a plus d’avenir pour le poste de développeur, et de ce fait le développeur va être remplacé.
Maintenant on revient à des choses un peu plus pragmatiques et concrètes. Ce n’est pas le développeur qui va être remplacé. Cependant la personne qui n’intègre pas l’IA, c’est sûr qu’elle sera un peu plus challengée parce que justement elle va potentiellement être challengée par une personne qui maîtrise bien son usage et qui sera de fait, naturellement, beaucoup plus productive.
C’est notre usage interne qui donne des gains de productivité quand même bien important.

M.D. – Oui, extrêmement important. C’est-à-dire qu’on a réduit toutes les tâches sans plus-value, sans forte plus-value. Et on voit aujourd’hui, quand on discute avec les collaborateurs, qu’ils ont beaucoup plus de temps à consacrer à des tâches à haute plus-value, sur de l’algorithmique, sur des choses bien précises, mais la génération de code tant que telle peut-être aujourd’hui à 60% confiée à une IA pour des portions de code. On ne parle pas d’architecture d’application, on parle bien de la génération de code spécifique.

P.M. – Donc une utilisation à bon escient d’un outil qui est magique mais qui ne va de toute évidence pas remplacer l’humain.

M.D. – Tout à fait.

P.M. – Vous savez qu’on vient d’un monde dit « Legacy », la plateforme IBM i, très souvent aussi employée sur son nom Legacy, l’AS/400. C’est une clientèle d’à peu près 25 000 clients dans le monde, avec des milliards de lignes de code, principalement RPG d’ailleurs, c’est plus de 85% des clients qui utilisent ce langage avec des applications dont le niveau de criticité est extrêmement élevé. C’est pour ça qu’elles sont toujours là, elles sont opérationnelles, elles ont évolué dans le temps pour répondre aux besoins du business. Donc c’est sûr qu’on pourrait dire qu’à un moment donné, toutes ces lignes de code vont être remplacées.
Là encore, ça serait vraiment une position très ayatollesque. Ce n’est absolument pas le cas. C’est valable aussi pour le langage COBOL qui restera encore des vieilles lignes de code qui vont continuer à faire tourner le monde et notamment des applications d’un niveau de criticité qui est absolument gigantesque. La question, c’est comment on va pouvoir utiliser à bon escient l’IBM i, enfin l’IA dans cet écosystème et faire en sorte de résoudre la problématique principale: le renouvellement des générations.
Alors Marc, qu’est-ce que tu peux nous dire sur comment tu vois l’IA en support de cette transformation ? À la fois humaine et aussi technologique.

M.D. – Quand on va moderniser une application, quand on va parler de processus de modernisation, je pense qu’il faut s’attacher à trois axes. Il va y avoir effectivement le code source de l’application qui est la base. Mais il y a aussi l’architecture de l’application et puis il y a l’interface machine, donc les interfaces utilisateurs. Et c’est ces trois axes-là qu’il va falloir travailler quand on va vouloir moderniser une application.
Mais on ne va pas utiliser les mêmes processus, soit techniques, soit cognitifs, pour moderniser ces trois axes. Je pense que l’IA aujourd’hui sur la modernisation du code, on le voit bien, tous les projets aujourd’hui qui sortent d’IA sont beaucoup orientés au niveau du code parce qu’on sait que c’est là où on a des gains de productivité. Donc sur le traitement du code, l’IA a toute sa place parce que c’est du traitement massif. Tu as parlé de plusieurs millions de lignes de code, donc l’IA peut vraiment travailler de façon extrêmement rapide et efficace pour moderniser du code dans sa transformation, dans sa compréhension. Quand on parle de modernisation, on peut aller jusqu’à l’abandon d’une plateforme, aussi pour des questions qui ne sont pas forcément technologiques d’ailleurs, qui peuvent être stratégiques au niveau de l’entreprise. Mais à un moment donné, on peut parler de modernisation pour une mutation ou pour un move-off, qu’on soit clair à ce niveau. Et là, on a besoin de comprendre, on a besoin d’extraire des règles de gestion d’un code.
Et ça, l’IA peut se substituer très avantageusement à un facteur humain, à une équipe humaine qui ne va faire qu’une reconnaissance, entre guillemets, de ces règles de gestion. Donc une IA entraînée, peut très facilement faire le travail d’une façon beaucoup plus efficace qu’un pool humain ou qu’une équipe humaine.
On a vraiment un facteur d’optimisation à travailler et à utiliser. Mais ça ne suffit pas parce qu’à un moment donné, on va parler de l’architecture d’application, qui va gérer la globalité des interactions entre les différents compléments du système.
Et notamment, on sait que les systèmes IBM i, l’architecture des applications, va faire intervenir des dizaines de milliers de composants en interaction entre eux, des composants de divers types d’ailleurs qui n’ont pas le même type de fonctionnement et le même type d’appréhension. Quand on va travailler sur l’architecture d’application, ça va être beaucoup plus compliqué pour une IA de comprendre ce niveau d’abstraction. Les IAs ne comprennent pas ce qu’elles font, elles sont capables d’expliquer et elles ne maîtrisent pas tout à fait cet aspect sémantique. Elle travaille en termes de statistiques donc sur du code ça va bien mais cette fois-ci, sur une architecture, la compréhension de l’architecture de l’application c’est beaucoup plus compliqué. Donc effectivement concernant cet axe là, on va voir que l’IA peut interagir et peut aider. Bien sûr qu’il y aura un apport de l’IA mais qui a tout un travail à faire avant et qui a une plus-value aujourd’hui de ce qu’on appelle les référentiels de métadonnées, c’est-à-dire qui vont décrire toutes ces interactions, et c’est l’interrogation, l’extraction de la connaissance dans ces interactions qu’on va pouvoir confier à une IA pour aller beaucoup plus vite dans la compréhension de l’architecture des applications.
Quand on va parler cette fois-ci de la modernisation des interfaces graphiques, c’est presque la dernière étape. C’est-à-dire qu’on est obligé d’avoir travaillé le code, l’architecture de l’application, et ensuite de générer des interfaces graphiques qui s’appuient sur cette première phase de modernisation.
Et là aussi, on a la capacité de pouvoir revenir dans la génération de codes, mais plus dans la génération de codes natifs, mais dans la génération de codes d’applications, et notamment des applications web aujourd’hui. C’est vrai, c’est vraiment cette direction qu’on doit mener. Et là, on va pouvoir régénérer du code d’applications web qui vont à l’avenir plus technique.
Et ce qu’on fait en interne, c’est qu’effectivement on utilise nos propres frameworks, mais on a entraîné un LLM à pouvoir générer du code sur nos propres outils, sur nos propres frameworks. On les a étendus notamment pour la génération d’interfaces web.

P.M. – Oui, donc ça c’est ce qu’on voit vraiment se dessiner, c’est ce à quoi on croit. Donc des front web, des applications web développées from scratch. C’est là où l’IA va donner un gain de productivité qui est absolument phénoménal et après la connexion avec le back-end et c’est là où va se développer – même si ça l’est déjà relativement – toutes ces notions de web services qui servent à faire la connexion entre un front complètement moderne et un back-end qui lui reste tel qu’il est et dont la valeur est toujours là puisque c’est ça qui fait tourner ces fameuses applications critiques.

M.D. – Il y a un point de vigilance qui est extrêmement important à mentionner ici, c’est que les IA peuvent être soumises à des hallucinations. Dans le cas d’une modernisation, on est obligé d’avoir des résultats prédictifs. C’est-à-dire qu’aujourd’hui, le monde n’est pas séparé entre toute IA et pas d’IA. Aujourd’hui, la bonne stratégie, c’est celle qu’on applique au sein d’ARCAD, c’est de mixer les deux et bien de réutiliser l’IA comme un outil. Mais ceci dit, avec le patrimoine technique et technologique qu’on a développé au sein d’ARCAD depuis maintenant plus de 30 ans, on a un certain nombre de mécanismes qui permettent de fournir des résultats prédictifs, basés sur des algorithmes, sur des bases de données où on est sûr de la qualité du résultat.
La stratégie aujourd’hui, c’est de mixer les deux. Et là, on arrive dans un monde qui est extrêmement pragmatique aujourd’hui. La modernisation, on peut effectivement parler de la baguette magique de l’IA, mais si on veut rester très pragmatique, c’est vraiment le mix de l’ensemble de ces outils.
Il y a des chaînes d’agents qui vont faire du prédictif, qui vont appeler l’IA, qui vont refaire du prédictif, qui vont appeler l’IA et ainsi de suite. C’est cette architecture aujourd’hui qui me paraît extrêmement importante à mettre en œuvre pour obtenir des résultats et fournir des résultats à nos clients, parce que c’est bien ça le but du jeu. Des résultats qui soient pertinents et qui soient réalisés et fournis dans un temps extrêmement court.

P.M. – D’accord. Voilà, ça c’est important. Tu as utilisé deux mots-clés absolument majeurs. L’un, c’est la notion d’architecture et le deuxième, c’est la notion de référentiel métadonnées.
Effectivement, en termes de connaissance de l’existant, c’est plus la partie architecture qui va être importante, la connaissance fonctionnelle beaucoup plus que la connaissance technique. L’IA n’a plus rien à prouver en ce qui concerne les connaissances techniques puisqu’on donne simplement la documentation du langage et tout naturellement on va être capable de créer des programmes selon l’état de l’art. Nous allons être extrêmement productifs dans la création de nouveaux programmes et aussi dans l’apprentissage de ce langage, qui peut paraître un peu ésotérique pour un développeur Java fraîchement sorti de l’école, mais qui finalement ne posera aucun problème. Car déjà dans sa syntaxe, il est très proche de .NET et de Java, mais il est aussi aidé par l’IA pour le comprendre. Le défi est plutôt de savoir comment ce jeune développeur, face à 10 ou 20 millions de lignes de code, va pouvoir trouver un bug ou modifier une règle de gestion, par exemple, dans une application critique où il sait qu’il n’a pas le droit à l’erreur, parce que l’impact peut être extrêmement important, surtout sur l’IBM i. C’est là où on introduit cette notion de référentiel de métadonnées. Ça, c’est le fruit de nos 33 ans d’expérience dans l’analyse d’applications existantes.
C’est des milliers d’applications qu’on a analysées de par le monde. Et la valeur ajoutée de la technologie ARCAD se situe dans cette source d’informations extrêmement riche, que j’illustrerais par exemple, dans un cerveau, il y a des milliards de neurones et des interconnexions entre toutes ces neurones, et le référentiel de métadonnées finalement c’est ça. C’est l’identification de toutes ces petites cellules, ces petits neurones. C’est le système d’information, et toutes ces interconnexions, c’est ça dont on a conscience. C’est d’être vraiment à la tête d’une richesse extrêmement élevée, justement pour toute cette clientèle IBM i. On va d’ailleurs pouvoir introduire notre nouveau produit qui est sorti l’année dernière, qui s’appelle Discover.
Marc, Discover, qu’est-ce qu’il contient, brièvement, outre cette source d’informations riche ?

M.D. – Discover, c’est effectivement, comme son nom l’indique, la capacité à découvrir une application ou l’intelligence intégrée dans une application. On va avoir une première partie d’analyse au niveau du code. C’est plutôt un outil dédié au business analyste, parce qu’on a dit que les développeurs vont plutôt agir au niveau du code, le business analyste agit plutôt au niveau de l’architecture de l’application.
Donc, on va avoir cette capacité à découvrir l’application. On va avoir la capacité à documenter l’application, c’est-à-dire qu’une fois qu’on a découvert un certain nombre de processus au sein de l’application, il est important de pouvoir les documenter, d’en garder une trace en tout cas.
On va pouvoir faire un état de santé de l’application initiale, c’est la partie Health check de Discover. Et on va même pouvoir rentrer dans ce qu’on appelle le Data Lineage, c’est-à-dire qu’on a parlé effectivement de l’architecture de l’application, mais il y a une couche transverse au-dessus de cette architecture d’application qui est la manipulation des données au sein de cette application.
C’est une couche transparente mais hautement stratégique. Aujourd’hui, on sait que la data, c’est quand même le nerf de la guerre et c’est quelque chose qui est extrêmement important. Et on a une partie qu’on appelle les vues macroscopiques qui permet d’avoir une vue top-down, plus fonctionnelle.
On parlait, il y a quelques décennies de ça, d’urbanisation de l’application, mais ce concept reste d’actualité, malgré tout, même si effectivement il est passé de mode dans sa terminologie, mais ça reste une nécessité absolue aujourd’hui de pouvoir identifier les différentes zones urbaines d’une application.

Discover a ces capacités d’exploiter les données d’une application, et notamment le référentiel de métadonnées, pour pouvoir retranscrire cette information à un haut niveau et au niveau des business analysis qui concernent des études.

P.M. – Comme vous l’avez compris, en fait on parle du code. On a des tas de mécanismes qui vont analyser ce code pour le transformer en composants, liens, zones, etc., tous les liens qu’il peut y avoir au sein du code lui-même. Donc il y a déjà une première couche d’attraction, et la deuxième couche étant, c’est là où l’IA va apporter beaucoup, puisque grâce à l’IA on va pouvoir déterminer les aires fonctionnelles et au fil de l’eau donc avoir une vision de plus en plus synthétique de quelque chose qui est réputé complexe.
J’ai tendance à le comparer à toutes les recherches qui sont faites autour du cerveau et là on voit bien que dans la maîtrise maintenant humaine, on sait qu’il y a des régions du cerveau qui sont dédiées à telle ou telle fonction, le niveau de connaissance en fait ne cesse d’augmenter et là pour le coup l’IA va beaucoup aider.

M.D. – Exactement. Je l’ai dit, aujourd’hui, Discover est plutôt un outil destiné aux business analystes. Donc, ça veut dire qu’il y a une rupture de langage entre les développeurs et les business analysts. On n’utilise pas la même terminologie, le business analyst n’est pas censé connaître le code source.
Et quand on va parler d’un composant de type programme. Un développeur, il va parler d’un programme, d’un fichier, de base de données, des choses comme ça. Pour l’analyste, dans son langage courant, ça n’a pas forcément de sens, il va parler de fonction, il va parler de soucis de système, il va parler de règles de gestion, de data.

P.M. – Oui, ce qui est intéressant pour lui, c’est de voir comment circule la donnée, et comment la donnée est transformée à travers le système informatique. C’est ce dont tu parlais à travers cette notion de data lineage. C’est : je pars d’une zone qui est affichée dans un écran et j’ai la capacité à suivre, à pister en fait, d’où elle vient au niveau base de données, comment elle est alimentée, quelles sont les règles de gestion en fait qui la manipulent.

M.D. – Mais au-delà de ça, cette différence de langage, elle peut procurer une rupture. C’est-à-dire que quand le business analyst va découvrir une application, il va interroger cette application avec son propre langage. Et ça, c’était important pour nous au niveau de Discover, de laisser la capacité au business analyst d’interroger notre référentiel avec son propre langage de business analyst.
Et c’est pour ça qu’une des fonctions majeures de Discover, c’est l’interrogation de ce référentiel de métadonnées en langage naturel. Le business analyst, lui, va interroger notre référentiel, même s’il a été construit de façon très technique à la base, avec des éléments techniques de connexion. Le business analyst va pouvoir l’interroger en langage naturel avec son propre langage. On résout la fracture de communication avec le langage, et ça, de manière itérative. Il va pouvoir poser une question qui reflète un problème d’analyse.
Il va pouvoir poser la question telle qu’elle et ça va être retranscrit par le mécanisme d’IA qu’on a intégré en un type de requête spécifique de façon à lui afficher un résultat qui soit compatible avec son niveau d’analyse et ce niveau d’abstraction dont on parlait tout à l’heure.
Et c’est ça la puissance aujourd’hui de l’intégration de l’IA dans Discover, c’est la résolution de cette fracture entre les deux mondes et de pouvoir interroger un référentiel de métadonnées avec ses propres contraintes fonctionnelles.

P.M. – C’est vous dire à quel point, en fait, on est en train de vivre aussi une révolution autour de ça et l’IA va apporter cette capacité à vraiment pouvoir interroger la manière dont est architecturé un système d’information et donner une ouverture à tout un tas de personnes qui ont besoin de ce type d’information.
Tu as évoqué les business analysts, mais au-delà de ça, il y a par exemple les data scientists qui ont besoin de savoir comment les datas sont architecturées les unes par rapport aux autres. Le champ d’usage de ce produit va bien au-delà du simple développeur, parce que justement, ça va contribuer à vulgariser cette information et faire en sorte que les gens du business soient plus autonomes dans cette compréhension et la capacité à faire des demandes qui soient cohérentes.

M.D. – Tout à fait. C’est vraiment important parce que si on revient à la question initiale qui était sur la modernisation, on sait que la modernisation, aujourd’hui, ce sont des projets qui impactent l’ensemble de l’entreprise.
Comme tu l’as dit, les applications IBM i, aujourd’hui, gèrent le backbone critique de l’entreprise. Et donc, ça veut dire que le choix de moderniser une application, ce n’est pas juste un choix technologique, ce n’est pas juste fait par les équipes de développement, c’est fait par l’ensemble des acteurs de l’entreprise, avec une mesure de risque qui va de la direction générale jusqu’au simple développeur.
Donc ça veut dire que tous les intervenants doivent pouvoir à un moment donné œuvrer à la mise en place de cette modernisation. Et l’avantage de Discover, et c’est comme ça qu’il a été désigné, c’est qu’on va pouvoir accepter différents acteurs au sein du même produit pour pouvoir réaliser des analyses qui sont spécifiques à chaque domaine, de façon à ce que tout le monde soit rassuré et tout le monde puisse mesurer et quantifier l’ampleur de la modernisation. Et ça, on réduit le risque, on augmente le facteur de confiance, et c’est effectivement un succès de réussite d’un projet de modernisation avec l’utilisation sous-jacente de l’IA telle qu’on l’a présentée, avec un mix entre l’IA et notre référentiel de métadonnées et avec une expérience de 30 ans sur ça.

P.M. – Oui, ça fait à peu près 25 ou 30 ans qu’on parle de modernisation. C’est vrai que ça a commencé à la base sur tout simplement la modernisation d’interface. Les gens ne voulaient plus des interfaces un peu moches, 5250, d’écran vert et noir.
Par contre, là maintenant, les enjeux sont bien différents parce que il y a même des entreprises qui vont garder pour certains ponts fonctionnels les écrans 5250. Donc je pense au fin fond d’un entrepôt qui utilise les douchettes, il n’y a strictement aucun intérêt de faire face aux interfaces web. Il faut que ça soit rapide et tout au clavier. A l’inverse, ce qui est intéressant, c’est qu’on voit qu’on va avoir beaucoup plus de flexibilité de son système d’information parce que ce sont des pans fonctionnels entiers qu’on va pouvoir décider de basculer, par exemple, sur un progiciel consommable en SaaS, tout en gardant un corps qui reste là extrêmement critique et la composition de cet ensemble va être beaucoup plus facile à partir du moment où justement on va pouvoir maîtriser toutes ces interactions.

M.D. – Effectivement, là maintenant, on parle de la phase d’après, c’est-à-dire qu’une fois qu’on a découvert l’application, qu’on a maintenant une vue très fine de l’architecture de l’application, maintenant il va falloir passer sur la phase de modernisation et comme tu l’as dit, la phase de la modernisation de l’interface parce que c’est aussi un facteur extrêmement important de modernisation de pouvoir offrir ces nouvelles interfaces pour les nouveaux acteurs qui vont interagir avec le système.
Et ça sous-entend qu’il y a une modification de l’architecture elle-même de l’application pour basculer vers du microservice. Donc, c’est-à-dire grosse phase de refactoring, reconnaissance du code. L’intelligence artificielle a toute sa place pour pouvoir rendre de façon très efficace les règles nécessaires à ce refactoring.
Mais on voit aussi le lier à des outils qui vont être en capacité de générer ces web services et de générer aussi les applications qui vont appeler ces web services. Donc c’est dans ce cadre, tu le mentionnais tout à l’heure, qu’on va pouvoir réadresser des IA différentes, cette fois-ci en termes de génération de code, mais sur d’autres types d’applications que sont les interfaces web.
Mais il y aura de toute façon cette phase de modernisation à faire. On l’a préparée, il faut la réaliser. Et effectivement, on va pouvoir utiliser des produits comme Transformer Microservices, par exemple, chez nous, qui acceptent, qui scannent le code, qui permettent à un moment donné de réaliser ce refactoring d’une application pour générer des microservices qui vont être utilisés ensuite par ces nouveaux types d’applications.
On va faire appel à de l’IA pour générer soit tout, soit en partie en tout cas le squelette applicatif.

P.M. – Oui, il y a aussi le code réellement utilisé, ça c’est quand même distinguer le code réellement utilisé de celui qui est mort. Autant concentrer ses efforts sur ce qu’il a réellement utilisé. On sait qu’une application qui a 30 ans d’âge, c’est en moyenne à peu près simplement la moitié qui est réellement en usage. Et le code redondant, parce qu’il y a beaucoup de vieilles habitudes avec énormément de copier-coller, qui font qu’on se retrouve avec des volumes de codes qui n’ont pas lieu d’être.
Donc ça fait beaucoup de sujets sur lesquels on voit très bien que l’IA va vraiment largement contribuer à restructurer son système d’information tout en prenant le moins de risques possibles quand même. Il faut quand même garder ça en tête. Là, on est en phase d’application critique. Les modifier comme ça, il y a forcément une appréhension qui est extrêmement élevée. Les garde-fous, on en a déjà parlé, entre autres sur la vulnérabilité du code, sont importants.
Mais dans notre outillage, on a aussi toute la partie test, et notamment le test de non-regression.

M.D. – Le test de non-regression, ça va être primordial pour ce type de projet. Globalement, on ne fait pas de modification. Quand on parle de modernisation, on n’ajoute pas potentiellement de nouvelles fonctionnalités. On essaie d’être dans un périmètre ISO en sortie. Donc là, le test de régression a toute sa valeur, que ce soit peut-être pas forcément au niveau de l’interface dans un premier temps, parce qu’effectivement on va modifier l’interface, mais en tout cas, en termes de résultats de sortie sur des programmes batch, on doit garantir qu’on n’a pas de régression, alors à la fois sur les sorties, mais aussi sur la base de données. C’est-à-dire que dans cet aspect un peu invisible de la manipulation de données, il faut être en capacité de faire des tests d’orientation, non seulement en termes de sortie, d’entrée-sortie, mais aussi en termes de base de données pour éviter des effets de corruption long terme invisibles qui d’un seul coup émergent six mois ou sept mois après et qui à un moment donné ont corrompu l’ensemble de la date.
On a des outils pour ça, des outils pour le coup non orientés IA, mais qui sont prédictifs, parce que là on a besoin d’avoir quelque chose de prédictif et pas quelque chose de statistique en disant que c’est bon à 80%. il faut que ce soit bon à 100% pour ce type de projet.

P.M. – C’était un aperçu de nos grandes orientations à la fois R&D. Comme vous avez pu constater on est quand même parfaitement à l’aise avec l’IA, à la fois en interne et aussi dans nos différents outils.
Ce ne sont pas les seuls outils du brand ARCAD qui vont être impactés par l’introduction de technologies IA. Je pense entre autres qu’il y a DROPS pour le Release Management, l’automatisation des processus de mise en production. Il va pouvoir y avoir un apport notamment dans tout ce qui est contrôle des anomalies, filmer les anomalies, ce qu’on appelle l’AIOps. Et puis, comme vous le savez aussi, on a un gros pied dans l’anonymisation des données personnelles, avec un processus en amont qui consiste à découvrir les données personnelles.
Là aussi, l’IA, de toute évidence, va apporter une vraie plus-value, puisque ça va contribuer à augmenter la productivité dans cette phase initiale, qui est indispensable après pour anonymiser ces données. Donc on est au début d’une aventure qui va durer quand même un peu plus de temps, mais qui est absolument passionnante.