Le développement logiciel à Inria doit répondre principalement à deux exigences : la qualité scientifique et la qualité technologique. Définir précisément ce que sont la qualité scientifique et la qualité technologique n’est pas le propos de cet article. Néanmoins, afin de pouvoir expliquer le défi qui est posé à chaque développeur de logiciel chez Inria (chercheur ou ingénieur), il est nécessaire, pour chacune d’elle, de s’en donner une définition simplifiée.
Qualité scientifique et qualité technologique
On peut dire d’un logiciel qu’il possède une bonne ou mauvaise qualité scientifique si les algorithmes qu’il contient permettent ou non de produire des publications scientifiques. Nous considérerons dans la suite qu’il existe un seuil de publication permettant de caractériser la qualité scientifique d’un logiciel.
D’un autre côté, il y a plusieurs manières de définir la qualité technologique d’un logiciel : architecture, modularité, performance, robustesse, portabilité sont autant d’attributs pertinents. Toutefois, par soucis de simplicité et pour faire écho au seuil de publication scientifique, nous dirons d’un logiciel qu’il possède une qualité technologique satisfaisante s’il est transférable en l’état vers le monde socio-économique. On utilisera donc un seuil de transfert pour définir la qualité technologique.
Cette modélisation simplifiée des qualités d’un logiciel, si discutable qu’elle soit, va nous permettre malgré tout de comprendre en quoi réside la difficulté de produire du logiciel à Inria.
Des exigences antagonistes dans la pratique
Deux populations distinctes s’adonnent au développement logiciel chez Inria :
- la population des chercheurs composée essentiellement de membres permanents, de doctorants, de post-docs et de stagiaires en master;
- la population des ingénieurs formée des ingénieurs permanents des Services d’Expérimentation et de Développement (SED), des ingénieurs en CDD recrutés via les Actions de Développement Technologiques (ADT), via des contrats collaboratif type ANR/H2020 ou encore sur des contrats bilatéraux avec des partenaires industriels.
Lorsqu’ils interviennent sur un logiciel les membres de ces deux populations ne suivent généralement pas les mêmes objectifs.
Cas d’un doctorant
Le but d’un doctorant quand il code va être le plus souvent d’implémenter le plus rapidement possible l’algorithme sur lequel il travaille afin de produire les résultats qui lui permettront de rédiger son papier et de le soumettre soit à une conférence soit à un journal. Il cherchera donc à ce que le logiciel franchisse le seuil de publication au plus vite sans trop se soucier de sa qualité technologique.
Cas d’un ingénieur ADT
À l’opposé, un ingénieur travaillant dans une ADT va d’abord chercher, car c’est la mission qui lui est assignée, à jeter les bases qui permettront au logiciel d’atteindre des standards technologiques suffisants, quitte à ce que le logiciel soit dans un premier temps dénué de toute qualité scientifique.
Qualité scientifique vs qualité technologique
Du point de vu du développement logiciel dans le contexte scientifique d’Inria, on peut donc considérer que qualité scientifique et qualité technologique sont des objectifs antagonistes difficilement réalisables simultanément. Pour mieux comprendre cette situation, rien de tel qu’un bon schéma :
Le plan formé par l’axe de la qualité scientifique et l’axe de la qualité technologique est découpé en quatre cadrans par le biais des deux seuils :
- le cadran 1 regroupe les logiciels dont les qualités scientifiques et technologiques sont insufisantes;
- le cadran 2 rassemble les logiciels possédant une bonne qualité technologique mais une mauvaise quatité scientifique;
- le cadran 3 réunit les logiciels de bonnes qualité scientifique mais de piètre qualité technologique;
- le cadran 4 est celui qui contient les logiciels qui satisfont aux deux exigences simultanément.
Répartition des logiciels Inria
Du fait de l’assymétrie numérique en faveur des chercheurs, il est naturel de trouver chez Inria essentiellement des logiciels présentant une bonne qualité scientifique et une moins bonne qualité technologique. Nous pouvons caricaturer la situation de la façon suivante :
Si la qualité scientifique d’un logiciel est évidemment essentielle dans le contexte de la recherche à Inria, les déficiences techniques deviennent au fil du temps de plus en plus problématiques. Une conséquence très pénalisante de ces déficiences pour une équipe-projet est le fait d’allouer près de 80% du temps dévolu au développement logiciel à la maintenance de parties de code qui ne relèvent pas du coeur de métier de l’équipe. Résultat, le temps disponible pour améliorer la qualité scientifique du logiciel se réduit comme peau de chagrin. Il devient alors indispensable de procéder à un remaniement du logiciel pour améliorer sa qualité technologique.
Une trajectoire illusoire
Considérons le cas d’une équipe-projet classique qui au cours de son existence a accumulé grâce aux contributions des différents doctorants et autres membres qui se sont succédés une collection de codes plus ou moins cousins, plus ou moins éloignés, fruits d’une savante succession d’échanges, de copier-coller et de patchs. Les savoir-faire scientifiques acquis au sein de cette collection sont incontestables mais y en ajouter des nouveaux nécessite de plus en plus souvent de modifier des bouts entiers de code rendant les éléments de la collection de plus en plus incompatibles et obligeant les membres de l’équipe à connaître et maîtriser ces différences, lesquelles portent généralement sur des aspects périphériques au domaine scientifique de l’équipe mais qui pour autant sont indispensables pour le bon fonctionnement de l’ensemble.
L’amélioration de la qualité technologique devient alors une priorité car elle permettra de maintenir le niveau de production scientifique de l’équipe. On recourt donc à un ingénieur (via une ADT par exemple) dont la mission est d’amener la collection de codes de l’équipe du cadran 3 où elle se trouve directement vers le cadran 4, le tout typiquement en tout juste 24 mois.
L’expérience montre qu’une telle trajectoire, pour idéale qu’elle soit, est illusoire. Ne serait-ce que parce qu’il est nécessaire de changer de paradigme de programmation pour atteindre les bons standards technologiques ou parce qu’il faut changer de langage. En outre, la contrainte de temps empêche d’envisager la migration complète de toutes les fonctionnalités de la collection initiale. De plus, l’isolement de l’ingénieur s’avère également handicapant. Il doit comprendre ce que font les codes alors même qu’il n’existe peu ou pas de documentation et que leurs auteurs ont quitté Inria il y a fort longtemps. Il doit modifier ces codes sans introduire d’erreur mais sans pour autant avoir tous les tests de non-régression à disposition et il doit, car c’est souvent ce qui est décrit comme le plus important, préserver voire augementer les performances et la robustesse. Et pendant ce temps là, les membres de l’équipe continuent de modifier les codes de la collection, modifications qui impactent très souvent le travail de migration de l’ingénieur.
La solution le plus souvent employée est alors de réduire la voilure : on se concentre sur un sous-ensemble de la collection initiale pour l’amener dans le cadran 4 et on se résoud à avoir des états transitoires dans les cadrans 1 et 2.
Une telle trajectoire n’est que très rarement envisagée en tout début de projet, et comme on doit cheminer par le même trajet pour l’ensemble des fonctionnalités de la collection initiale, il est clair que le temps accordé à l’ingénieur est insuffisant pour pouvoir procéder à la migration complète. Qu’à cela ne tienne, il suffit pour l’équipe de redemander une ressource ingénieur pour réussir la migration.
En imaginant que l’on procède à trois ADT successives de deux ans chacunes, il faudra donc 6 années calendaires pour effectuer la totalité de la migration. Une telle durée pose a minima trois problèmes :
- premièrement, elle peut amener à une date de fin postérieure à la fin de l’équipe-projet
- deuxièmenent, elle laisse la possibilité à une solution concurrente d’émerger ce qui nuirait à la notoriété du logiciel et à sa diffusion
- deuxièmement, elle soumet le logiciel à des forces contraires qui mettront malgré tout en échec le travail de migration
Obsolescences scientifiques et technologiques
Les deux forces contraires qui s’opposent à la réussite de la migration du cadran 3 vers le cadran 4 sont l’obsolescence scientifique et l’obsolescence technologique. Ces forces s’expriment d’autant plus fortement que la durée de la migration s’accroît.
Reprenons notre durée de 6 ans et considérons une fonctionnalité de la collection du cadran 3. Cette fonctionnalité est souvent issue d’un travail bien antérieur à la première ADT. Il n’est donc pas inimaginable qu’un changement de paradigme opère dans le domaine scientifique de l’équipe-projet rendant la fonctionnalité obsolète qui de fait ne franchit plus le seuil de publication. La trajectoire de la migration ne mène alors plus dans le cadran 4 mais juste dans le cadran 2.
Le risque d’une durée de migration trop longue est d’obtenir un logiciel désuet sur le plan scientifique bien loin des exigences de publication.
Reste que l’effort consenti a permis de produire un logiciel dont les bases technologiques sont assainies. Ceci doit quand même permettre à l’équipe d’y ajouter de nouvelles fonctionnalités scientifiques franchissant le seuil de publication pour enfin atteindre le cadran 4 tant convoité.
Malheureusement, même du point de vu technologique, rien n’est acquis face à une durée de développement trop étendue. En effet, les choix technologiques effectués au début du projet peuvent s’avérer dépassés au bout du compte. Finalement, la trajectoire de migration s’en trouve encore modifiée et conduit seulement dans une zone à la lisière du cadran 1 et du cadran 2.
L’ironie de l’histoire est que sans intervention d’ingénieurs, suite aux dérives scientifiques et technologiques, la collection aurait terminé dans le cadran 1.
L’existence des forces de dérives explique également pourquoi même lorsqu’on a atteint le cadran 4, s’y maintenir ne peut se faire qu’au prix d’un coût de maintenance élevée, ce qui implique de diposer de ressources humaines quasi permanentes.
Accélérer la vitesse de développement
- équipe de dev
- implication totale de l’équipe projet sur des cycles courts
- formation des doctorant au génie logiciel et au transfert
Assurer la maintenance
- transfert industriel des fonctionnalités dépassées scientifiquement mais pas industriellement
- communauté de développeurs / InriaSoft
- start-up
