Heny SELMI, BI Manager chez Mantu Group – Data Science Consultant chez Mantu-Amaris Consulting, Tunis
Cependant, les besoins métiers en matière de science des données dominent de plus en plus les objectifs commerciaux des entreprises, et évoluent pour rendre plus rapide et moins coûteux le développement de systèmes d'IA. Mais l’enjeu qui devient exponentiellement plus complexe et coûteux, sera de savoir déployer et maintenir ces systèmes au fil du temps.
En effet, les équipes Data Science sont confrontés quotidiennement à une énorme dette technique en déployant des systèmes, sans les processus structurés et une boite à outils assez riches pour assurer la maintenabilité, le contrôle, la surveillance ainsi que les mises à jour nécessaires.
De plus, le traitement des « mauvaises » qualités de données (affaire de tous les jours pour les Data Scientists) créent un travail imprévu et provoquent des erreurs qui invalident les résultats, ce qui impose aux équipes Data Science de produire dans un cadre de travail plus agile, mais s’adaptant à la nature de leurs missions.
Il y a quelques années, Gartner a prédit que 85% des projets « Data » ne seraient pas gérés par la DSI.
Forrester a confirmé cette situation inacceptable en déclarant que 75% des projets d'IA et de Data Science sont décevants.
Nous ne pouvons pas affirmer que les projets professionnels ou industriels de Data Science échouent uniquement pour des raisons liées au cadres de travail, méthodologies, structurations, etc., mais ne pas utiliser une méthodologie de travail et conduire un état d’esprit agile avec un CICD (Intégration Continue et Déploiement Continu), mettent en péril la réussite du projet.
On peut dire, qu’à partir de notre expérience de travail avec les Data Scientists, et ce dans plusieurs cadres (académiques, professionnels, industriels, R&D, compétitions, etc.), que ces problèmes sont réels. En ajoutant également que la plupart des jeunes Data Scientists consacrent la majorité de leurs efforts à la modélisation, tout en négligeant ainsi un tas de sujets assez importants liés à la phase de déploiement, notamment la planification de la livraison, le monitoring, la planification des supports, la formation des utilisateurs ou des décideurs, la publication, l’identification des améliorations, la construction d’une stratégie de test, etc.
Heureusement, les équipes de science des données peuvent relever ces défis en appliquant des leçons appris dans l'industrie du logiciel, mais se posent toujours les questions suivantes :
- Quelles sont les méthodologies de travail en data science ?
- Devant cette panoplie de méthodes et processus, comment choisir la plus appropriée à la nature de la mission ?
- Quels sont les outils de gestions de projets ? de contrôle de version ? de CICD ? etc.
En effet, les équipes Data Science sont confrontés quotidiennement à une énorme dette technique en déployant des systèmes, sans les processus structurés et une boite à outils assez riches pour assurer la maintenabilité, le contrôle, la surveillance ainsi que les mises à jour nécessaires.
De plus, le traitement des « mauvaises » qualités de données (affaire de tous les jours pour les Data Scientists) créent un travail imprévu et provoquent des erreurs qui invalident les résultats, ce qui impose aux équipes Data Science de produire dans un cadre de travail plus agile, mais s’adaptant à la nature de leurs missions.
Il y a quelques années, Gartner a prédit que 85% des projets « Data » ne seraient pas gérés par la DSI.
Forrester a confirmé cette situation inacceptable en déclarant que 75% des projets d'IA et de Data Science sont décevants.
Nous ne pouvons pas affirmer que les projets professionnels ou industriels de Data Science échouent uniquement pour des raisons liées au cadres de travail, méthodologies, structurations, etc., mais ne pas utiliser une méthodologie de travail et conduire un état d’esprit agile avec un CICD (Intégration Continue et Déploiement Continu), mettent en péril la réussite du projet.
On peut dire, qu’à partir de notre expérience de travail avec les Data Scientists, et ce dans plusieurs cadres (académiques, professionnels, industriels, R&D, compétitions, etc.), que ces problèmes sont réels. En ajoutant également que la plupart des jeunes Data Scientists consacrent la majorité de leurs efforts à la modélisation, tout en négligeant ainsi un tas de sujets assez importants liés à la phase de déploiement, notamment la planification de la livraison, le monitoring, la planification des supports, la formation des utilisateurs ou des décideurs, la publication, l’identification des améliorations, la construction d’une stratégie de test, etc.
Heureusement, les équipes de science des données peuvent relever ces défis en appliquant des leçons appris dans l'industrie du logiciel, mais se posent toujours les questions suivantes :
- Quelles sont les méthodologies de travail en data science ?
- Devant cette panoplie de méthodes et processus, comment choisir la plus appropriée à la nature de la mission ?
- Quels sont les outils de gestions de projets ? de contrôle de version ? de CICD ? etc.
Data science et commercialisation : quelles exigences des entreprises ?
La gestion de la science des données est une discipline émergente. Il sera essentiel pour atteindre l'impact transformationnel anticipé et de plus en plus exigé par les leaders mondiaux du Business.
Au même temps, le succès de la science des données peut être perçu comme un art sombre pour ceux qui ne possèdent pas assez de connaissance en pratique. L’intérêt médiatique omniprésent n'a fait qu'exacerber la situation à mesure que le risque de déception et de désillusion augmente. Les spécialistes de la science des données sont invités à multiplier leur impact sans une feuille de route claire sur la manière de faire évoluer leurs capacités actuelles.
La science des données est en train de passer d'une capacité de niche exploitée par quelques pionniers à une capacité de base dans toutes les entreprises. Pendant l’ère data, tout ce qui était autrefois « nice to have » est devenu un impératif de survie, et les besoins qui étaient « externalisés » constituent aujourd’hui le cœur de l’activité des entreprises.
Comme pour l'évolution du développement logiciel, l'outillage a considérablement progressé ces dernières années. Mais aussi comme les logiciels développement, l'outillage seul ne suffit pas. Le durcissement des nouveaux rôles entre les différents membres de l’équipe, des processus et des technologies sera essentiel pour consolider la position de la science des données en tant que fonction centrale.
Dans notre expérience de travail avec des organisations de science des données, grandes et petites, nous avons vu des thèmes récurrents dans les défis de gestion auxquels ils sont confrontés ; la cause sous-jacente de ces défis ; et un ensemble de principes et de meilleures pratiques qui ont permis le succès à grande échelle.
Au même temps, le succès de la science des données peut être perçu comme un art sombre pour ceux qui ne possèdent pas assez de connaissance en pratique. L’intérêt médiatique omniprésent n'a fait qu'exacerber la situation à mesure que le risque de déception et de désillusion augmente. Les spécialistes de la science des données sont invités à multiplier leur impact sans une feuille de route claire sur la manière de faire évoluer leurs capacités actuelles.
La science des données est en train de passer d'une capacité de niche exploitée par quelques pionniers à une capacité de base dans toutes les entreprises. Pendant l’ère data, tout ce qui était autrefois « nice to have » est devenu un impératif de survie, et les besoins qui étaient « externalisés » constituent aujourd’hui le cœur de l’activité des entreprises.
Comme pour l'évolution du développement logiciel, l'outillage a considérablement progressé ces dernières années. Mais aussi comme les logiciels développement, l'outillage seul ne suffit pas. Le durcissement des nouveaux rôles entre les différents membres de l’équipe, des processus et des technologies sera essentiel pour consolider la position de la science des données en tant que fonction centrale.
Dans notre expérience de travail avec des organisations de science des données, grandes et petites, nous avons vu des thèmes récurrents dans les défis de gestion auxquels ils sont confrontés ; la cause sous-jacente de ces défis ; et un ensemble de principes et de meilleures pratiques qui ont permis le succès à grande échelle.
Une problématique purement opérationnelle !
Naturellement, les projets Data Science proviennent d’un objectif métier. Les données sont souvent imparfaites, l’équipe doit nettoyer, préparer, masquer, normaliser et manipuler les données afin qu’elles puissent être utilisées efficacement. L’extraction des fonctionnalités identifie les métriques (valeurs mesurées) qui sont informatives et faciliter la formation. Après les phases de construction et d’évaluation, le modèle est déployé et ses performances sont contrôlées.
Ainsi, si les contraintes métier ou data changent, l’équipe des Data Scientists devrait être informée à temps afin d’anticiper... Ce processus continue aussi longtemps que le modèle est utilisé.
DevOps, qui a inspiré le nom DataOps, se concentre sur la livraison continue en tirant parti des ressources informatiques à la demande et en automatisant le test et le déploiement du code. Imaginer en cliquant sur un bouton pour tester et publier de nouvelles analyses d’apprentissage machine en production. Cette fusion du développement de logiciels et des opérations informatiques réduit le temps de déploiement et diminue le délai de commercialisation, minimise les défauts et raccourcit le temps nécessaire pour résoudre les problèmes.
Etant donné que c’est une méthode emportée de DevOps, DataOps bénéficie des mêmes améliorations pour la Data Science.
Ainsi, si les contraintes métier ou data changent, l’équipe des Data Scientists devrait être informée à temps afin d’anticiper... Ce processus continue aussi longtemps que le modèle est utilisé.
DevOps, qui a inspiré le nom DataOps, se concentre sur la livraison continue en tirant parti des ressources informatiques à la demande et en automatisant le test et le déploiement du code. Imaginer en cliquant sur un bouton pour tester et publier de nouvelles analyses d’apprentissage machine en production. Cette fusion du développement de logiciels et des opérations informatiques réduit le temps de déploiement et diminue le délai de commercialisation, minimise les défauts et raccourcit le temps nécessaire pour résoudre les problèmes.
Etant donné que c’est une méthode emportée de DevOps, DataOps bénéficie des mêmes améliorations pour la Data Science.
DataOps : vers un Framework « agile »
DataOps est une méthodologie automatisée et orientée processus, utilisée par les équipes d’analyse et de données, pour améliorer la qualité et réduire le temps de cycle de l’analyse des données. Elle tire parti de l’automatisation, des outils de gestion de la demande, de livraison et d’autres meilleures pratiques.
Tout comme le manifeste Agile, le DataOps possède sa version manifesto signée par plus que 5000 personnes au monde, et qui dispose de 18 principes issus du code suivant :
Individus et interactions sur les processus et outils
Fonctionnement des analyses de données sur l’intégralité de la documentation
Collaboration du client sur la négociation du contrat
Expérimentation, itération, et feedback sur la conception approfondie initiale
Propriété transversale des opérations sur les responsabilités compartimentées
Quant aux principes ; vous avez la possibilité de les trouver sur le site : https://www.dataopsmanifesto.org/
Cependant, l’implémentation de la DataOps nécessitera l’application des six étapes suivantes :
Étape 1 - Ajouter des tests de données et satisfaire les exigences métier
Pour être certain que le pipeline d'analyse de données fonctionne correctement, il devrait être testée. Ces tests détectent les erreurs et avertissements potentiels avant leur publication, de sorte que la qualité de toute production reste garantie. Les tests manuels sont longs et laborieux. Un test robuste et automatisé est un élément crucial dans le processus de la livraison continue.
Étape 2 - Utilisez un système de contrôle et de gestion de version (Versioning)
Tout traitement qui transforme les données brutes en informations utiles devrait être conservé et mis à jour. Tous les artefacts que les Data Scientists créent pendant la phase de modélisation, constituent l’ensemble des codes sources (exécutés, testés, déployés, etc.). Ces codes assurent l'intégralité du pipeline d'analyse de données de bout en bout afin de construire un système automatisé et reproductible, dans le sens où il serait possible à tout moment de reprendre n’importe quelle version de code pour des finalités d’analyse et de test. Ce processus sera assuré par les logiciels de gestion de version VCS (Version Control System), comme GIT et TFS.
Généralement, les codes associés à l'analyse sont distribués à travers divers endroits dans une organisation incontrôlable. Un outil de gestion de versions, permet de gérer toutes les modifications apportées au code. Il maintient également le code principal (en production), dans un référentiel et assure la reprise en cas d’incident. Le contrôle de révision aide également les équipes à paralléliser leurs efforts en leur permettant de se ramifier et de fusionner leurs travaux sans pour autant impacter l’activité en production.
Étape 3 - Branche et Merge
Lorsqu’un membre de l’équipe de science des données souhaite effectuer des mises à jour, il devrait tout d’abord procéder à la récupération de l’ensemble des codes validés et en production, et ce à l’aide du système de contrôle des révisions. Ce qui lui permettra d’apporter des modifications en local, sur une copie privée du code. Ces changements locaux sont considérés comme la branche de travail, sur laquelle il pourra tester ses propres modifications.
Un telle pratique augmente la productivité de l'équipe en permettant aux membres de l’équipe Data Science de travailler simultanément sur des succursales.
Lorsque les modifications apportées à la branche sont terminées, testées et validées pour fonctionner, le code peut être revu dans le contrôle de révision, fusionnant ainsi de nouveau dans le tronc (le code opérationnel principal).
Le « branching » et le « merging » permettent à l'équipe de science des données d'exécuter ses propres tests, d'apporter des modifications, prendre des risques et expérimenter. Si un ensemble de changements s'avère infructueux, la succursale peut être mis au rebut, et le membre de l'équipe peut recommencer.
Étape 4 - Utiliser plusieurs environnements
Lorsque l'équipe qui crée de nouvelles analyses reçoit son propre environnement, elle peut itérer rapidement sans se soucier de l'impact sur les opérations. L'IaaS (infrastructure en tant que service) facilite la configuration des environnements de développement et de test, de telle façon que ces nouveaux environnements correspondent exactement aux opérations. Cela permet d'éviter de pointer du doigt entre la modélisation, l'assurance des exigences métiers et la livraison.
Il convient de souligner à nouveau que les scientifiques des données ont besoin d'une copie des données. Dans le passé, la création des copies des bases de données coûtait cher. Avec le stockage à la demande des services cloud, l'ensemble des données peut être copié rapidement, et à peu de frais, pour réduire les conflits et les dépendances. Si les données sont encore trop volumineuses pour être copiées, elles peuvent être échantillonnées. Dans tous les cas, avec la richesse des écosystèmes Big Data, on pourra toujours trouver des remèdes à la volumétrie.
Étape 5 - Réutiliser et conteneuriser
Les membres de l'équipe de science des données ont généralement du mal à tirer parti du travail de chacun. La réutilisation du code est un vaste sujet, mais l'idée de base est de segmenter les fonctionnalités entre tous les membres de l’équipe afin d’assurer un partage de connaissances du code, et d’en faciliter les processus de HandOver. Les fonctions complexes, avec de nombreuses pièces individuelles, peuvent être « conteneurisées » à l'aide d'une technologie de conteneur (comme Docker). Les conteneurs sont idéaux pour les fonctions hautement personnalisées qui nécessitent un ensemble de compétences qui n'est pas largement partagé par l'équipe.
Étape 6 - Orchestrez deux volets
De nombreux professionnels de la science des données redoutent le déploiement des changements impactant les systèmes de production ou permettant aux données de mauvaise qualité d'atteindre les utilisateurs. Pour y remédier, il faut optimiser les pipelines de valeur et d'innovation. Dans le pipeline de valeur (production), les données entrent dans la production et créent de la valeur pour l'organisation, on parle généralement de Proof of Value, POV. Dans le pipeline d'innovation, les idées, sous la forme de nouvelles analyses et de la science des données, sont en cours de développement et peuvent être ajoutées au pipeline de valeur.
Les deux pipelines se croisent pendant que de nouvelles analyses se déploient dans les opérations. L'entreprise DataOps maîtrise l'orchestration des données vers la production, et le déploiement de nouvelles fonctionnalités, tout en maintenant une qualité irréprochable. Avec des tests (contrôle statistique des processus) contrôlant et surveillant à la fois les données et les nouveaux pipelines de développement, l'équipe de développement des modèles Machine Learning peut déployer sans se soucier d’impacter les systèmes de production. Ainsi, la DataOps garantit la maximisation du temps consacré aux nouvelles analyses.
Le tableau ci-dessous montre comment les sept étapes de DataOps sont directement liées aux étapes du modèle développement. Par exemple, l'orchestration automatise la préparation des données, extraction de fonctionnalités, formation et déploiement de modèles. Contrôle de version, branche et merge, environnements, réutilisation et conteneurs et paramétrage s'appliquent tous à ces mêmes phases. Les tests s'appliquent à toutes les phases du cycle de vie du modèle.
Tout comme le manifeste Agile, le DataOps possède sa version manifesto signée par plus que 5000 personnes au monde, et qui dispose de 18 principes issus du code suivant :
Individus et interactions sur les processus et outils
Fonctionnement des analyses de données sur l’intégralité de la documentation
Collaboration du client sur la négociation du contrat
Expérimentation, itération, et feedback sur la conception approfondie initiale
Propriété transversale des opérations sur les responsabilités compartimentées
Quant aux principes ; vous avez la possibilité de les trouver sur le site : https://www.dataopsmanifesto.org/
Cependant, l’implémentation de la DataOps nécessitera l’application des six étapes suivantes :
Étape 1 - Ajouter des tests de données et satisfaire les exigences métier
Pour être certain que le pipeline d'analyse de données fonctionne correctement, il devrait être testée. Ces tests détectent les erreurs et avertissements potentiels avant leur publication, de sorte que la qualité de toute production reste garantie. Les tests manuels sont longs et laborieux. Un test robuste et automatisé est un élément crucial dans le processus de la livraison continue.
Étape 2 - Utilisez un système de contrôle et de gestion de version (Versioning)
Tout traitement qui transforme les données brutes en informations utiles devrait être conservé et mis à jour. Tous les artefacts que les Data Scientists créent pendant la phase de modélisation, constituent l’ensemble des codes sources (exécutés, testés, déployés, etc.). Ces codes assurent l'intégralité du pipeline d'analyse de données de bout en bout afin de construire un système automatisé et reproductible, dans le sens où il serait possible à tout moment de reprendre n’importe quelle version de code pour des finalités d’analyse et de test. Ce processus sera assuré par les logiciels de gestion de version VCS (Version Control System), comme GIT et TFS.
Généralement, les codes associés à l'analyse sont distribués à travers divers endroits dans une organisation incontrôlable. Un outil de gestion de versions, permet de gérer toutes les modifications apportées au code. Il maintient également le code principal (en production), dans un référentiel et assure la reprise en cas d’incident. Le contrôle de révision aide également les équipes à paralléliser leurs efforts en leur permettant de se ramifier et de fusionner leurs travaux sans pour autant impacter l’activité en production.
Étape 3 - Branche et Merge
Lorsqu’un membre de l’équipe de science des données souhaite effectuer des mises à jour, il devrait tout d’abord procéder à la récupération de l’ensemble des codes validés et en production, et ce à l’aide du système de contrôle des révisions. Ce qui lui permettra d’apporter des modifications en local, sur une copie privée du code. Ces changements locaux sont considérés comme la branche de travail, sur laquelle il pourra tester ses propres modifications.
Un telle pratique augmente la productivité de l'équipe en permettant aux membres de l’équipe Data Science de travailler simultanément sur des succursales.
Lorsque les modifications apportées à la branche sont terminées, testées et validées pour fonctionner, le code peut être revu dans le contrôle de révision, fusionnant ainsi de nouveau dans le tronc (le code opérationnel principal).
Le « branching » et le « merging » permettent à l'équipe de science des données d'exécuter ses propres tests, d'apporter des modifications, prendre des risques et expérimenter. Si un ensemble de changements s'avère infructueux, la succursale peut être mis au rebut, et le membre de l'équipe peut recommencer.
Étape 4 - Utiliser plusieurs environnements
Lorsque l'équipe qui crée de nouvelles analyses reçoit son propre environnement, elle peut itérer rapidement sans se soucier de l'impact sur les opérations. L'IaaS (infrastructure en tant que service) facilite la configuration des environnements de développement et de test, de telle façon que ces nouveaux environnements correspondent exactement aux opérations. Cela permet d'éviter de pointer du doigt entre la modélisation, l'assurance des exigences métiers et la livraison.
Il convient de souligner à nouveau que les scientifiques des données ont besoin d'une copie des données. Dans le passé, la création des copies des bases de données coûtait cher. Avec le stockage à la demande des services cloud, l'ensemble des données peut être copié rapidement, et à peu de frais, pour réduire les conflits et les dépendances. Si les données sont encore trop volumineuses pour être copiées, elles peuvent être échantillonnées. Dans tous les cas, avec la richesse des écosystèmes Big Data, on pourra toujours trouver des remèdes à la volumétrie.
Étape 5 - Réutiliser et conteneuriser
Les membres de l'équipe de science des données ont généralement du mal à tirer parti du travail de chacun. La réutilisation du code est un vaste sujet, mais l'idée de base est de segmenter les fonctionnalités entre tous les membres de l’équipe afin d’assurer un partage de connaissances du code, et d’en faciliter les processus de HandOver. Les fonctions complexes, avec de nombreuses pièces individuelles, peuvent être « conteneurisées » à l'aide d'une technologie de conteneur (comme Docker). Les conteneurs sont idéaux pour les fonctions hautement personnalisées qui nécessitent un ensemble de compétences qui n'est pas largement partagé par l'équipe.
Étape 6 - Orchestrez deux volets
De nombreux professionnels de la science des données redoutent le déploiement des changements impactant les systèmes de production ou permettant aux données de mauvaise qualité d'atteindre les utilisateurs. Pour y remédier, il faut optimiser les pipelines de valeur et d'innovation. Dans le pipeline de valeur (production), les données entrent dans la production et créent de la valeur pour l'organisation, on parle généralement de Proof of Value, POV. Dans le pipeline d'innovation, les idées, sous la forme de nouvelles analyses et de la science des données, sont en cours de développement et peuvent être ajoutées au pipeline de valeur.
Les deux pipelines se croisent pendant que de nouvelles analyses se déploient dans les opérations. L'entreprise DataOps maîtrise l'orchestration des données vers la production, et le déploiement de nouvelles fonctionnalités, tout en maintenant une qualité irréprochable. Avec des tests (contrôle statistique des processus) contrôlant et surveillant à la fois les données et les nouveaux pipelines de développement, l'équipe de développement des modèles Machine Learning peut déployer sans se soucier d’impacter les systèmes de production. Ainsi, la DataOps garantit la maximisation du temps consacré aux nouvelles analyses.
Le tableau ci-dessous montre comment les sept étapes de DataOps sont directement liées aux étapes du modèle développement. Par exemple, l'orchestration automatise la préparation des données, extraction de fonctionnalités, formation et déploiement de modèles. Contrôle de version, branche et merge, environnements, réutilisation et conteneurs et paramétrage s'appliquent tous à ces mêmes phases. Les tests s'appliquent à toutes les phases du cycle de vie du modèle.
Conclusion
Alors que les outils de la data science améliorent la productivité du développement de modèles, le code Machine Learning est une petite partie de la solution système globale. Les équipes de science des données qui ne suivent pas les principes d’un cycle de vie des données peuvent se retrouver avec une mauvaise qualité et une dette technique, qui entraîne des travaux imprévus.
DataOps propose une nouvelle approche pour créer et opérationnaliser la data science, assurant ainsi une minimisation importante des problèmes techniques la dette, réduisant le temps de cycle et améliorant la qualité du code et des données. C’est un cadre de travail qui permet aux équipes de science des données de prospérer malgré les niveaux de complexité croissants requis pour déployer et maintenir la data science sur le terrain. Il dissocie les opérations, de la nouvelle création analytique, et les rejoint dans le cadre automatisé de la livraison continue. L'orchestration des chaînes d'outils de modélisation, de déploiement, d'exploitation et de surveillance simplifient considérablement les flux de travail quotidiens de l'équipe de science des données. Sans le fardeau de la dette technique et du travail imprévu, ils peuvent se concentrer sur leur domaine d’expertise ; créer de nouveaux modèles qui aident l'entreprise à réaliser sa mission. Maintenant, la question qui va se poser, peut-on éviter d’assembler plusieurs outils de gestion dans le même cadre ? Actuellement, l’outil TDSP peut constituer un cadre de travail complet permettant la gestion du projet, le suivi, la gestion des demandes, le versioning, etc.
DataOps propose une nouvelle approche pour créer et opérationnaliser la data science, assurant ainsi une minimisation importante des problèmes techniques la dette, réduisant le temps de cycle et améliorant la qualité du code et des données. C’est un cadre de travail qui permet aux équipes de science des données de prospérer malgré les niveaux de complexité croissants requis pour déployer et maintenir la data science sur le terrain. Il dissocie les opérations, de la nouvelle création analytique, et les rejoint dans le cadre automatisé de la livraison continue. L'orchestration des chaînes d'outils de modélisation, de déploiement, d'exploitation et de surveillance simplifient considérablement les flux de travail quotidiens de l'équipe de science des données. Sans le fardeau de la dette technique et du travail imprévu, ils peuvent se concentrer sur leur domaine d’expertise ; créer de nouveaux modèles qui aident l'entreprise à réaliser sa mission. Maintenant, la question qui va se poser, peut-on éviter d’assembler plusieurs outils de gestion dans le même cadre ? Actuellement, l’outil TDSP peut constituer un cadre de travail complet permettant la gestion du projet, le suivi, la gestion des demandes, le versioning, etc.
