A lire sur: http://www.it-expertise.com/tierces-parties-reelles-economies-ou-pas/
Les
logiciels que l’on développe aujourd’hui sont couramment composés de
briques logicielles spécialisées, techniques ou applicatives. Depuis
l’avènement d’internet, des composants spécialisés touchants à de
nombreux domaines d’activités ont été et sont toujours développés par
des organisations et entreprises en tous points du globe. Ces briques
logicielles développées par ces acteurs tiers, ont pour vocation de
faciliter et normaliser le développement des logiciels. Le développement
de ceux-ci permet une délégation de la dette technique et une réduction
de l’incertitude quant à la réussite des projets. Leur utilisation se
traduit généralement, en apparence, par une réduction des coûts et des
risques liés au développement logiciel avec potentiellement une
réactivité accrue en termes de développements.
L’utilisation de librairies tierces parties est une pratique courante dans le milieu de l’ingénierie logicielle. Alors même que leur intégration est une pratique ancrée dans les mœurs sans réelles conventions, le sujet semble peu considéré dans la littérature. Les promesses d’économies réalisées ne sont toutefois pas systématiquement tenues et pire, un manque de préparation peut avoir des répercussions dramatiques pouvant causer l’échec d’un projet logiciel. Un composant tierce partie est un composant spécialisé, technique ou applicatif, désigné et développé par des ingénieurs et sociétés tiers. Ces composants ont pour vocation d’être intégrés au développement de logiciels sous la forme de scripts, librairies ou Framework. Le code source qui les compose peut être disponible, comme c’est le cas dans le cadre de composants open source, ou protégé dans les autres cas.
Du point de vue de l’ingénieur, la raison première de leur utilisation tient à l’économie de temps à ne pas développer ce qui existe et qui peut être réutilisé, tant qu’il répond raisonnablement aux besoins exprimés. D’un point de vue plus général, il existe de très nombreuses motivations à leur utilisation, toutes ayant pour but d’effectuer des économies.
Quelles raisons motivent leur utilisation ? Quelles sont les conséquences sur le cycle de vie du logiciel ? Quels éléments permettent de limiter les coûts identifiés ?
Le gain de temps et de réactivité sont la motivation première de l’utilisation d’une tierce partie. D’autres motivations peuvent également toucher à des problèmes de compétences sur des domaines considérés annexes vis-à-vis de l’activité de développement du logiciel.
Malgré toutes les études et dogmes créés autour de l’ingénierie logicielle, les risques liés à la réussite ou l’échec d’un projet de développement logiciel sont toujours élevés. Une pratique qui permet de réduire les risques consiste à désigner et réutiliser des composants techniques ou fonctionnels. Les composantes tierces parties sont souvent le fruit des expériences des ingénieurs répondant à des défis qu’ils ont pu rencontrer au fil de leurs projets. Il s’agit de composants qui ont été conçus pour être réutilisables pour d’autres projets. En plus d’être développé par des acteurs externes, les composants sont maintenus par ces mêmes acteurs. Bien que ce support puisse être payant, l’économie est d’autant plus grande que ce support peut être réparti sur les différents utilisateurs. C’est particulièrement important lorsqu’on estime le coût de la maintenance dans le cycle de vie d’un logiciel. Cette en maintenance pourra être transférée vers du développement fonctionnel générateur de valeur.
Un élément essentiel de tout composant informatique est la documentation. La compréhension des services fournis et de leur mise en pratique passe systématiquement par la mise en place de documentation adaptée. Les retours d’utilisations viennent peupler les « frequently asked questions » (faq) qui faciliteront l’identification de solutions aux problèmes connus. Sur certains projets, des forums de discussion permettent aux communautés d’échanger et de bénéficier de l’expertise d’autres utilisateurs. Les utilisateurs sont à même de développer et partager leur propre documentation pour compléter celle déjà fournie. C’est moins vrai pour des composants développés en internes du fait de toutes les contraintes imposées par les projets. C’est pire quand il s’agit de librairies techniques, rarement documentées..
Puisqu’une large communauté d’utilisateurs peut se former autour de ces composants, les problèmes rencontrés peuvent être identifiés dans une large proportion. De part une utilisation variée, les bugs et limitations sont rapidement mis en exergue et des solutions peuvent être apportées rapidement. Cela contribue à augmenter le niveau de qualité des services..
Pour les projets open source, les communautés de contributeurs travaillent souvent dans un contexte plus orienté quality-driven que cost-driven. Dans ce contexte, les projets de faible qualité (piètre performances, difficultés de maintenance ou d’évolution) ont tendance à perdre leurs contributeurs et utilisateurs.
Utiliser des tierces parties, c’est également accélérer l’intégration de nouveaux ingénieurs qui, en terrain connu, prendront en main le code applicatif plus rapidement. Cela facilite l’interopérabilité des différents acteurs du développement. C’est également un simplificateur de recrutement pour l’entreprise qui peut cibler plus précisément les profils recherchés.
Mieux encore, l’utilisation de tierces parties permet de déléguer des compétences non nécessairement présentes dans une entreprise et de s’abstraire des détails techniques sous-jacents. Les problématiques propres aux domaines et aux contraintes d’utilisations vont trouver des réponses adaptées : performance, sécurité, évolutivité.
L’utilisation de ces composants peut également permettre aux ingénieurs les employant de développer ces domaines de compétences. Par leur usage, l’utilisateur se trouve naturellement inscrit dans un cadre qui renforce les bonnes pratiques du domaine.
Si l’on considère uniquement les bons côtés, on pourrait en venir à considérer que le développement logiciel doit se faire systématiquement à l’aide de tierces parties quand elles sont disponibles. Au fur et à mesure de l’avancement dans le cycle de vie du logiciel, cependant, de nombreux dangers interviennent. En effet, lorsque les problèmes sont identifiés, il est souvent trop tard pour un retour en arrière. Malgré leur grand nombre, les inconvénients listés ci-dessous ne se cumulent que rarement :
Les auteurs et entreprises développant du logiciel protègent leur création à l’aide de licences. Les licences protègent d’une part l’utilisation de ces logiciels et d’autre part le code source qui les composent. Il existe des combinaisons multiples de licences permettant un usage gratuit ou payant, avec droits de modifications ou non du code source.
Ces licences sont très nombreuses. Une mauvaise appréhension de leur coût ou limites peut entrainer des conséquences dramatiques. Un composant utilisé peut entrainer des procédures judiciaires avec compensations financières, voire un retrait du composant. Dès que le problème de licence est identifié, plusieurs solutions s’offrent à l’utilisateur : régulariser le paiement des licences, débrancher et remplacer le composant, désactiver les fonctionnalités reposant sur ce composant ou abandonner le logiciel. Chaque solution peut être extrêmement coûteuse, en particulier si le problème est détecté après la mise en production du logiciel.
Au-delà de la notion de licence, une entreprise fournit un service tiers, sous la forme de développements ou de composants logiciels directement intégrés. Les pratiques de programmations peuvent inclure de mauvaises pratiques destinées à lier l’utilisateur. Un service de piètre qualité aura immanquablement des répercussions sur le cycle de vie du logiciel.
Le composant tierce partie employé peut être trop volumineux, pour l’emploi que l’on peut en faire. Intégrer un framework qui fournit un grand nombre de fonctionnalités dont on n’utilisera qu’un petit nombre peut complexifier une application. L’intégration au code peut être abusivement compliquée de par la nature du framework qui par son ampleur peut être plus enclin à contenir de nombreux bugs de fonctionnement. Cela handicape la testabilité du code développé et a des répercussions sur le moyen terme en coûts de maintenance. De par sa taille ou l’absence d’accès au code source, l’utilisateur peut faire face à un effet « boite noire ».
Tout aussi gênant, le framework employé ne fournit pas tous les services escomptés ou des écarts entre la documentation et le fonctionnement réel sont constatés. L’ingénieur risque alors de devoir développer des fonctionnalités dans un contexte de code qui n’est pas nécessairement son environnement de prédilection. Cela peut générer des temps d’arrêt dans le projet et des coûts supplémentaires importants lors de migrations ou d’évolutions. Une solution peut être de faire cohabiter plusieurs librairies fournissant des services équivalents pour ne prendre que le meilleur. Ce type d’approche donne des résultats imprédictibles.
Comme tout projet informatique, un composant tierce partie évolue au fil du temps et l’on peut être contraint de suivre ces évolutions. Dans le cas où le code est indisponible et que les évolutions dépendent des investissements effectués par la compagnie exploitante, les bugs existants peuvent être une gêne importante bloquant certaines fonctionnalités. Il convient dès lors d’identifier des solutions qui peuvent passer par le (re)développement de ces composants défaillants quand cela est possible. Ce problème peut être atténué dans le cas de composants open source dans la mesure où les problèmes identifiés peuvent être corrigés. La correction peut dès lors être partagée avec la communauté.
Il est nécessaire de s’assurer de la compatibilité du code et des données lorsque le logiciel ou ses composants évoluent. Un exemple simple montre la difficulté du problème : les évolutions des logiciels de traitement de textes. Au fil des versions, de nouvelles fonctionnalités exigent des modifications structurelles des fichiers contenant les données. Il faut être capable de continuer à lire les fichiers tels qu’ils étaient sauvegardés par le passé (compatibilité ascendante). On peut observer dans ces logiciels de nombreux effets de bords.
Les composantes tierces parties ont une problématique similaire mais les contraintes techniques peuvent exiger des transformations du code les employant. Cela devient purement dramatique quand l’utilisateur se retrouve contraint de suivre les évolutions. Ce sera typiquement le cas d’un framework touchant au développement web dont on sait que les navigateurs et les normes évoluent encore constamment. Si l’on souhaite que notre application web fonctionne sur les nouvelles versions de navigateurs, il faudra la faire évoluer.
Le composant tierce partie peut être abandonné pour plusieurs raisons: société en faillite, désintérêt de ses contributeurs ou sur-classement par un nouveau composant. Si une telle situation se produit, il faudra tôt ou tard planifier des évolutions : identifier un remplaçant, apprendre à l’utiliser puis l’intégrer. Ceci remettant de fait en cause du code existant dont on sait qu’il fonctionnait bien et que des régressions peuvent survenir.
Un autre problème concernant les évolutions est la direction de celles-ci. Le composant employé peut répondre à nos besoins, cependant, sa roadmap peut suivre une direction qui n’est pas celle souhaitée par tous ses utilisateurs. Des fonctionnalités employées peuvent se trouver modifiées, dépréciées, voire supprimées.
Des bonnes pratiques permettent heureusement de s’en sortir face aux dilemmes qui s’invitent. Il convient de cadrer le choix des tierces parties et leur modalité d’intégration au sein des projets informatiques afin de tenter de limiter les risques.
Le premier point concerne les licences et là, à défaut pour l’entreprise de disposer d’ingénieurs sensibilisés, il faut assurer des formations, sensibilisations et études. Des outils d’analyse permettent depuis peu d’effectuer des audits et de mettre au clair les licences des composants employés dans le développement d’un logiciel.
Avant de choisir une tierce partie, il convient de réaliser une étude préalable portant sur les fonctionnalités, la stabilité, l’état d’investissement de la communauté. Puisque plusieurs outils existent qui peuvent fournir des services équivalents, il convient d’effectuer des comparaisons entre les différents outils, idéalement au travers de prototypes qui permettront de « stresser » le composant.
Il est courant qu’une tierce partie ne fournisse pas 100% des fonctionnalités souhaitées. Il faut donc établir la liste des fonctionnalités prioritaires et le coût de développement des fonctionnalités non présentes. C’est le bon moment pour effectuer une première comparaison entre les tierces parties et exclure des candidats potentiels tant il sera impossible de tous les évaluer avec précision.
L’investissement de la communauté est un élément primordial. Le support, la maintenance et les évolutions doivent être soutenues dans une durée équivalente au cycle de vie du logiciel les utilisant. On pourra souvent préférer un outil moins abouti en début de vie avec une communauté réactive qu’un autre plus complet en fin de vie maintenu par un ingénieur sur son temps libre. Un outil tierce partie perd souvent sa communauté quand les fonctionnalités fournies ou son cœur technique deviennent obsolètes et que les évolutions deviennent couteuses. Ce n’est cependant pas toujours le cas ; on peut imaginer que des outils de parsing xml ou des algorithmes de structures de données soient stabilisés et relativement figés depuis quelques années tout en restant d’actualité.
Une fois que quelques solutions sont identifiées, il reste à faire le choix final de la tierce partie qui sera la bonne à un instant donné. Après expérimentation, l’utilisateur peut identifier celle avec laquelle il se sentira en confiance. Il restera ensuite à décider d’un mode d’intégration. C’est à cet instant que l’ingénieur doit établir, une politique qui permettra d’anticiper un éventuel retour en arrière.
On distingue deux types d’intégrations de tierces parties : franche ou timide. La première approche, peut être considérée comme optimiste : on fait pleinement confiance dans la tierce partie et on considère qu’elle sera présente jusqu’à la fin du cycle de vie du logiciel. Si l’on ne peut pas être aussi confiant, une bonne pratique consiste à considérer la possibilité de retirer la tierce partie dès son intégration. Ce faisant, on s’efforce d’éviter les adhérences du code qui augmenteront significativement le risque lors de désintégrations éventuelles.
Dans le cadre de l’intégration franche, on ne met pas en place de politique d’intégration spécifique. On utilise la tierce partie comme un projet informatique adjacent à ceux qui l’utilisent. Elle deviendra partie intégrante du logiciel. Les mises à jour entraineront des risques de régressions, nécessitant tests unitaires et d’intégrations. Le retrait se montrera probablement impossible à entamer et les migrations devront être soigneusement cadrées. On peut toutefois s’adonner à ce type d’intégration dans le cadre de librairies maitrisables de petites tailles d’une grande stabilité fonctionnelle et technique. Ce sera typiquement le cas du parseur de ressources xml ayant fait ses preuves depuis quelques années. Ce sera également le cas d’un framework volumineux qui embarque ses bonnes pratiques et contraint fortement la façon de développer le code reposant dessus.
Lorsqu’on anticipe le retrait et les évolutions de la tierce partie, une intégration plus structurée peut être mise en place qui consiste à définir des interfaces. L’interface est une façade interne permettant de contrôler les accès du code à la tierce partie. L’utilisateur ne voit la tierce partie qu’au travers de cette interface. Avant d’aller plus loin sur le sujet, il faut considérer les évolutions futures ; pour ce faire, une mécanique de version peut être accolée aux interfaces. L’utilisateur peut réclamer une version précise de la librairie. Cette précision permet de cibler les risques autour des migrations et de les effectuer de façon incrémentale.
Au travers de ces interfaces, l’utilisateur n’a pas de visibilité directe de la tierce partie. Il n’a pas à exprimer d’expertises qui lui seraient propres et peut se concentrer sur ses bénéfices fonctionnels tels que définis via l’interface. L’intérêt est direct car en cas de changement de librairie ou de migration, le risque est ciblé sur l’interface. Des tests unitaires et d’intégrations permettent d’identifier rapidement les régressions et d’assurer l’iso-fonctionnalité de l’interface.
Un autre bénéfice concerne le masquage d’une complexité technique inhérente au domaine fonctionnel ou aux choix d’intégrations de la tierce partie (cf figure). La compétence technique non centrale se concentre sur les intégrateurs plutôt que les utilisateurs. L’utilisateur n’a donc pas à connaitre ou à rencontrer les problèmes déjà identifiés ainsi que leurs solutions.
Cette approche permet un découpage plus clair vers les composants extérieurs et aide à réduire les « codes spaghettis » et leurs adhérences fortes. La librairie peut être remplacée/migrée avec potentiellement moins de risques de régressions.
Une avancée supplémentaire concerne une forme d’extension des interfaces au travers d’une mise en abstraction. Les interfaces décrites pour une tierce partie se concentrent généralement sur le domaine fonctionnel de cette dernière. Ainsi, on peut définir des interfaces orientées métier. On peut ainsi cacher des « détails » techniques et se concentrer sur le code applicatif dans un paradigme qui porte du sens pour l’utilisateur. Dans cette optique, l’utilisateur, s’il n’est pas l’intégrateur, devra contribuer au processus d’intégration car il sera le premier concerné par l’utilisation.
Les interfaces peuvent donc être de vraies façades masquant autant que possible la technicité pour proposer au développeur un outil adapté à son environnement. Ce faisant, on risque cependant de perdre le bénéfice de la documentation disponible et les compétences sur ces tierces parties perdent de leur attrait sur les profils à l’embauche. On peut aisément noter comment l’approche architecturelle peut avoir un impact sur la politique d’embauche et vice et versa.
L’utilisation de tierces parties ne garantit ni succès, ni économie ou pérennité dans le cadre du développement d’une application. Le choix d’un composant tiers doit être étayé par une analyse amont et dépendra fortement du contexte d’utilisation de celui-ci. La modularité d’une application, notamment vis-à-vis de ce type de composant, au travers d’une architecture bien pensée est dans tous les cas un gage de réduction de risque.
Cédric Hartland
Docteur en informatique – R&D Engineer
CAST est le pionnier et leader mondial de l’analyse et de la mesure des applications, une approche automatisée pour mesurer la qualité, la complexité et la taille des applications logicielles. CAST apporte une visibilité objective et sans précédent pour mesurer la performance et piloter efficacement les activités de développement, de maintenance et de sourcing. Plus de 250 grandes entreprises font confiance à CAST pour prévenir les risques et les interruptions de service tout en réduisant les couts de développement IT. Avec près de 75 millions d’euros investis en R&D, CAST est partie intégrante des process de delivery et de maintenance des plus importantes SSII mondiales telles que Atos, Capgemini, IBM et Steria.
http://www.castsoftware.com
Utilisation des tierces parties
L’utilisation de librairies tierces parties est une pratique courante dans le milieu de l’ingénierie logicielle. Alors même que leur intégration est une pratique ancrée dans les mœurs sans réelles conventions, le sujet semble peu considéré dans la littérature. Les promesses d’économies réalisées ne sont toutefois pas systématiquement tenues et pire, un manque de préparation peut avoir des répercussions dramatiques pouvant causer l’échec d’un projet logiciel. Un composant tierce partie est un composant spécialisé, technique ou applicatif, désigné et développé par des ingénieurs et sociétés tiers. Ces composants ont pour vocation d’être intégrés au développement de logiciels sous la forme de scripts, librairies ou Framework. Le code source qui les compose peut être disponible, comme c’est le cas dans le cadre de composants open source, ou protégé dans les autres cas.
Du point de vue de l’ingénieur, la raison première de leur utilisation tient à l’économie de temps à ne pas développer ce qui existe et qui peut être réutilisé, tant qu’il répond raisonnablement aux besoins exprimés. D’un point de vue plus général, il existe de très nombreuses motivations à leur utilisation, toutes ayant pour but d’effectuer des économies.
Quelles raisons motivent leur utilisation ? Quelles sont les conséquences sur le cycle de vie du logiciel ? Quels éléments permettent de limiter les coûts identifiés ?
Tout se paie, le bien…
Le gain de temps et de réactivité sont la motivation première de l’utilisation d’une tierce partie. D’autres motivations peuvent également toucher à des problèmes de compétences sur des domaines considérés annexes vis-à-vis de l’activité de développement du logiciel.
Une histoire de gains
Malgré toutes les études et dogmes créés autour de l’ingénierie logicielle, les risques liés à la réussite ou l’échec d’un projet de développement logiciel sont toujours élevés. Une pratique qui permet de réduire les risques consiste à désigner et réutiliser des composants techniques ou fonctionnels. Les composantes tierces parties sont souvent le fruit des expériences des ingénieurs répondant à des défis qu’ils ont pu rencontrer au fil de leurs projets. Il s’agit de composants qui ont été conçus pour être réutilisables pour d’autres projets. En plus d’être développé par des acteurs externes, les composants sont maintenus par ces mêmes acteurs. Bien que ce support puisse être payant, l’économie est d’autant plus grande que ce support peut être réparti sur les différents utilisateurs. C’est particulièrement important lorsqu’on estime le coût de la maintenance dans le cycle de vie d’un logiciel. Cette en maintenance pourra être transférée vers du développement fonctionnel générateur de valeur.
Un élément essentiel de tout composant informatique est la documentation. La compréhension des services fournis et de leur mise en pratique passe systématiquement par la mise en place de documentation adaptée. Les retours d’utilisations viennent peupler les « frequently asked questions » (faq) qui faciliteront l’identification de solutions aux problèmes connus. Sur certains projets, des forums de discussion permettent aux communautés d’échanger et de bénéficier de l’expertise d’autres utilisateurs. Les utilisateurs sont à même de développer et partager leur propre documentation pour compléter celle déjà fournie. C’est moins vrai pour des composants développés en internes du fait de toutes les contraintes imposées par les projets. C’est pire quand il s’agit de librairies techniques, rarement documentées..
Puisqu’une large communauté d’utilisateurs peut se former autour de ces composants, les problèmes rencontrés peuvent être identifiés dans une large proportion. De part une utilisation variée, les bugs et limitations sont rapidement mis en exergue et des solutions peuvent être apportées rapidement. Cela contribue à augmenter le niveau de qualité des services..
Pour les projets open source, les communautés de contributeurs travaillent souvent dans un contexte plus orienté quality-driven que cost-driven. Dans ce contexte, les projets de faible qualité (piètre performances, difficultés de maintenance ou d’évolution) ont tendance à perdre leurs contributeurs et utilisateurs.
Une histoire de compétences
Utiliser des tierces parties, c’est également accélérer l’intégration de nouveaux ingénieurs qui, en terrain connu, prendront en main le code applicatif plus rapidement. Cela facilite l’interopérabilité des différents acteurs du développement. C’est également un simplificateur de recrutement pour l’entreprise qui peut cibler plus précisément les profils recherchés.
Mieux encore, l’utilisation de tierces parties permet de déléguer des compétences non nécessairement présentes dans une entreprise et de s’abstraire des détails techniques sous-jacents. Les problématiques propres aux domaines et aux contraintes d’utilisations vont trouver des réponses adaptées : performance, sécurité, évolutivité.
L’utilisation de ces composants peut également permettre aux ingénieurs les employant de développer ces domaines de compétences. Par leur usage, l’utilisateur se trouve naturellement inscrit dans un cadre qui renforce les bonnes pratiques du domaine.
…plus cher que le mal
Si l’on considère uniquement les bons côtés, on pourrait en venir à considérer que le développement logiciel doit se faire systématiquement à l’aide de tierces parties quand elles sont disponibles. Au fur et à mesure de l’avancement dans le cycle de vie du logiciel, cependant, de nombreux dangers interviennent. En effet, lorsque les problèmes sont identifiés, il est souvent trop tard pour un retour en arrière. Malgré leur grand nombre, les inconvénients listés ci-dessous ne se cumulent que rarement :
Business ne rime pas toujours avec qualité et bonnes pratiques
Les auteurs et entreprises développant du logiciel protègent leur création à l’aide de licences. Les licences protègent d’une part l’utilisation de ces logiciels et d’autre part le code source qui les composent. Il existe des combinaisons multiples de licences permettant un usage gratuit ou payant, avec droits de modifications ou non du code source.
Ces licences sont très nombreuses. Une mauvaise appréhension de leur coût ou limites peut entrainer des conséquences dramatiques. Un composant utilisé peut entrainer des procédures judiciaires avec compensations financières, voire un retrait du composant. Dès que le problème de licence est identifié, plusieurs solutions s’offrent à l’utilisateur : régulariser le paiement des licences, débrancher et remplacer le composant, désactiver les fonctionnalités reposant sur ce composant ou abandonner le logiciel. Chaque solution peut être extrêmement coûteuse, en particulier si le problème est détecté après la mise en production du logiciel.
Au-delà de la notion de licence, une entreprise fournit un service tiers, sous la forme de développements ou de composants logiciels directement intégrés. Les pratiques de programmations peuvent inclure de mauvaises pratiques destinées à lier l’utilisateur. Un service de piètre qualité aura immanquablement des répercussions sur le cycle de vie du logiciel.
Une histoire de Framework qui fait aussi le café
Le composant tierce partie employé peut être trop volumineux, pour l’emploi que l’on peut en faire. Intégrer un framework qui fournit un grand nombre de fonctionnalités dont on n’utilisera qu’un petit nombre peut complexifier une application. L’intégration au code peut être abusivement compliquée de par la nature du framework qui par son ampleur peut être plus enclin à contenir de nombreux bugs de fonctionnement. Cela handicape la testabilité du code développé et a des répercussions sur le moyen terme en coûts de maintenance. De par sa taille ou l’absence d’accès au code source, l’utilisateur peut faire face à un effet « boite noire ».
Tout aussi gênant, le framework employé ne fournit pas tous les services escomptés ou des écarts entre la documentation et le fonctionnement réel sont constatés. L’ingénieur risque alors de devoir développer des fonctionnalités dans un contexte de code qui n’est pas nécessairement son environnement de prédilection. Cela peut générer des temps d’arrêt dans le projet et des coûts supplémentaires importants lors de migrations ou d’évolutions. Une solution peut être de faire cohabiter plusieurs librairies fournissant des services équivalents pour ne prendre que le meilleur. Ce type d’approche donne des résultats imprédictibles.
Comme tout projet informatique, un composant tierce partie évolue au fil du temps et l’on peut être contraint de suivre ces évolutions. Dans le cas où le code est indisponible et que les évolutions dépendent des investissements effectués par la compagnie exploitante, les bugs existants peuvent être une gêne importante bloquant certaines fonctionnalités. Il convient dès lors d’identifier des solutions qui peuvent passer par le (re)développement de ces composants défaillants quand cela est possible. Ce problème peut être atténué dans le cas de composants open source dans la mesure où les problèmes identifiés peuvent être corrigés. La correction peut dès lors être partagée avec la communauté.
Une histoire de survie des espèces…
Il est nécessaire de s’assurer de la compatibilité du code et des données lorsque le logiciel ou ses composants évoluent. Un exemple simple montre la difficulté du problème : les évolutions des logiciels de traitement de textes. Au fil des versions, de nouvelles fonctionnalités exigent des modifications structurelles des fichiers contenant les données. Il faut être capable de continuer à lire les fichiers tels qu’ils étaient sauvegardés par le passé (compatibilité ascendante). On peut observer dans ces logiciels de nombreux effets de bords.
Les composantes tierces parties ont une problématique similaire mais les contraintes techniques peuvent exiger des transformations du code les employant. Cela devient purement dramatique quand l’utilisateur se retrouve contraint de suivre les évolutions. Ce sera typiquement le cas d’un framework touchant au développement web dont on sait que les navigateurs et les normes évoluent encore constamment. Si l’on souhaite que notre application web fonctionne sur les nouvelles versions de navigateurs, il faudra la faire évoluer.
Le composant tierce partie peut être abandonné pour plusieurs raisons: société en faillite, désintérêt de ses contributeurs ou sur-classement par un nouveau composant. Si une telle situation se produit, il faudra tôt ou tard planifier des évolutions : identifier un remplaçant, apprendre à l’utiliser puis l’intégrer. Ceci remettant de fait en cause du code existant dont on sait qu’il fonctionnait bien et que des régressions peuvent survenir.
Un autre problème concernant les évolutions est la direction de celles-ci. Le composant employé peut répondre à nos besoins, cependant, sa roadmap peut suivre une direction qui n’est pas celle souhaitée par tous ses utilisateurs. Des fonctionnalités employées peuvent se trouver modifiées, dépréciées, voire supprimées.
Bonnes pratiques
Des bonnes pratiques permettent heureusement de s’en sortir face aux dilemmes qui s’invitent. Il convient de cadrer le choix des tierces parties et leur modalité d’intégration au sein des projets informatiques afin de tenter de limiter les risques.
Une histoire de choix
Le premier point concerne les licences et là, à défaut pour l’entreprise de disposer d’ingénieurs sensibilisés, il faut assurer des formations, sensibilisations et études. Des outils d’analyse permettent depuis peu d’effectuer des audits et de mettre au clair les licences des composants employés dans le développement d’un logiciel.
Avant de choisir une tierce partie, il convient de réaliser une étude préalable portant sur les fonctionnalités, la stabilité, l’état d’investissement de la communauté. Puisque plusieurs outils existent qui peuvent fournir des services équivalents, il convient d’effectuer des comparaisons entre les différents outils, idéalement au travers de prototypes qui permettront de « stresser » le composant.
Il est courant qu’une tierce partie ne fournisse pas 100% des fonctionnalités souhaitées. Il faut donc établir la liste des fonctionnalités prioritaires et le coût de développement des fonctionnalités non présentes. C’est le bon moment pour effectuer une première comparaison entre les tierces parties et exclure des candidats potentiels tant il sera impossible de tous les évaluer avec précision.
L’investissement de la communauté est un élément primordial. Le support, la maintenance et les évolutions doivent être soutenues dans une durée équivalente au cycle de vie du logiciel les utilisant. On pourra souvent préférer un outil moins abouti en début de vie avec une communauté réactive qu’un autre plus complet en fin de vie maintenu par un ingénieur sur son temps libre. Un outil tierce partie perd souvent sa communauté quand les fonctionnalités fournies ou son cœur technique deviennent obsolètes et que les évolutions deviennent couteuses. Ce n’est cependant pas toujours le cas ; on peut imaginer que des outils de parsing xml ou des algorithmes de structures de données soient stabilisés et relativement figés depuis quelques années tout en restant d’actualité.
Une fois que quelques solutions sont identifiées, il reste à faire le choix final de la tierce partie qui sera la bonne à un instant donné. Après expérimentation, l’utilisateur peut identifier celle avec laquelle il se sentira en confiance. Il restera ensuite à décider d’un mode d’intégration. C’est à cet instant que l’ingénieur doit établir, une politique qui permettra d’anticiper un éventuel retour en arrière.
Une histoire d’intégration
On distingue deux types d’intégrations de tierces parties : franche ou timide. La première approche, peut être considérée comme optimiste : on fait pleinement confiance dans la tierce partie et on considère qu’elle sera présente jusqu’à la fin du cycle de vie du logiciel. Si l’on ne peut pas être aussi confiant, une bonne pratique consiste à considérer la possibilité de retirer la tierce partie dès son intégration. Ce faisant, on s’efforce d’éviter les adhérences du code qui augmenteront significativement le risque lors de désintégrations éventuelles.
Dans le cadre de l’intégration franche, on ne met pas en place de politique d’intégration spécifique. On utilise la tierce partie comme un projet informatique adjacent à ceux qui l’utilisent. Elle deviendra partie intégrante du logiciel. Les mises à jour entraineront des risques de régressions, nécessitant tests unitaires et d’intégrations. Le retrait se montrera probablement impossible à entamer et les migrations devront être soigneusement cadrées. On peut toutefois s’adonner à ce type d’intégration dans le cadre de librairies maitrisables de petites tailles d’une grande stabilité fonctionnelle et technique. Ce sera typiquement le cas du parseur de ressources xml ayant fait ses preuves depuis quelques années. Ce sera également le cas d’un framework volumineux qui embarque ses bonnes pratiques et contraint fortement la façon de développer le code reposant dessus.
Lorsqu’on anticipe le retrait et les évolutions de la tierce partie, une intégration plus structurée peut être mise en place qui consiste à définir des interfaces. L’interface est une façade interne permettant de contrôler les accès du code à la tierce partie. L’utilisateur ne voit la tierce partie qu’au travers de cette interface. Avant d’aller plus loin sur le sujet, il faut considérer les évolutions futures ; pour ce faire, une mécanique de version peut être accolée aux interfaces. L’utilisateur peut réclamer une version précise de la librairie. Cette précision permet de cibler les risques autour des migrations et de les effectuer de façon incrémentale.
Au travers de ces interfaces, l’utilisateur n’a pas de visibilité directe de la tierce partie. Il n’a pas à exprimer d’expertises qui lui seraient propres et peut se concentrer sur ses bénéfices fonctionnels tels que définis via l’interface. L’intérêt est direct car en cas de changement de librairie ou de migration, le risque est ciblé sur l’interface. Des tests unitaires et d’intégrations permettent d’identifier rapidement les régressions et d’assurer l’iso-fonctionnalité de l’interface.
Un autre bénéfice concerne le masquage d’une complexité technique inhérente au domaine fonctionnel ou aux choix d’intégrations de la tierce partie (cf figure). La compétence technique non centrale se concentre sur les intégrateurs plutôt que les utilisateurs. L’utilisateur n’a donc pas à connaitre ou à rencontrer les problèmes déjà identifiés ainsi que leurs solutions.
Intégration via interfaces techniques et applicatives
Cette approche permet un découpage plus clair vers les composants extérieurs et aide à réduire les « codes spaghettis » et leurs adhérences fortes. La librairie peut être remplacée/migrée avec potentiellement moins de risques de régressions.
Une avancée supplémentaire concerne une forme d’extension des interfaces au travers d’une mise en abstraction. Les interfaces décrites pour une tierce partie se concentrent généralement sur le domaine fonctionnel de cette dernière. Ainsi, on peut définir des interfaces orientées métier. On peut ainsi cacher des « détails » techniques et se concentrer sur le code applicatif dans un paradigme qui porte du sens pour l’utilisateur. Dans cette optique, l’utilisateur, s’il n’est pas l’intégrateur, devra contribuer au processus d’intégration car il sera le premier concerné par l’utilisation.
Les interfaces peuvent donc être de vraies façades masquant autant que possible la technicité pour proposer au développeur un outil adapté à son environnement. Ce faisant, on risque cependant de perdre le bénéfice de la documentation disponible et les compétences sur ces tierces parties perdent de leur attrait sur les profils à l’embauche. On peut aisément noter comment l’approche architecturelle peut avoir un impact sur la politique d’embauche et vice et versa.
Conclusion
L’utilisation de tierces parties ne garantit ni succès, ni économie ou pérennité dans le cadre du développement d’une application. Le choix d’un composant tiers doit être étayé par une analyse amont et dépendra fortement du contexte d’utilisation de celui-ci. La modularité d’une application, notamment vis-à-vis de ce type de composant, au travers d’une architecture bien pensée est dans tous les cas un gage de réduction de risque.
Cédric Hartland
Docteur en informatique – R&D Engineer
CAST est le pionnier et leader mondial de l’analyse et de la mesure des applications, une approche automatisée pour mesurer la qualité, la complexité et la taille des applications logicielles. CAST apporte une visibilité objective et sans précédent pour mesurer la performance et piloter efficacement les activités de développement, de maintenance et de sourcing. Plus de 250 grandes entreprises font confiance à CAST pour prévenir les risques et les interruptions de service tout en réduisant les couts de développement IT. Avec près de 75 millions d’euros investis en R&D, CAST est partie intégrante des process de delivery et de maintenance des plus importantes SSII mondiales telles que Atos, Capgemini, IBM et Steria.
http://www.castsoftware.com
Aucun commentaire:
Enregistrer un commentaire