DÉPLOYER DES SOLUTIONS IT " FULL-CODE " GRÂCE À UNE APPROCHE DEVOPS - CONNECT YOUR BUSINESS TO THE NEXT LEVEL - SPIKEELABS
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
Connect your business to the next level Déployer des solutions IT « Full-Code » grâce à une approche DevOps.
LIVRE BLANC
/
Édito p.3
Introduction p.4
Un code source ouvert et évolutif p.5
Une architecture scalable p.10
Conclusion p.14
Usecases d’intégration p.15
Glossaire p.16
/
2
LIVRE BLANC
Edito
Les solutions ad-hoc reposant sur du code sur mesure ont longtemps été perçues comme complexes
et lentes en matière d’évolutions : elles nécessitent souvent beaucoup de développeurs
expérimentés, une infrastructure dédiée parfois conséquente et des process de validation et de mise
en production lourds.
Une tendance « No-Code » a alors émergé en promettant des logiciels configurables qui s’adaptent
à toutes les spécificités de l’utilisateur. Pour les problématiques communes à toute entreprise, ces
solutions peuvent être très efficaces, comme les outils de gestion des forces de vente ou de
comptabilité. Mais pour des problématiques très proches du métier d’une entreprise, leur intégration
aux processus en place nécessite bien souvent de tordre son fonctionnement, avec pour
conséquence une perte d’efficacité pour l’entreprise.
Chez SpikeeLabs, nous estimons que les applications clés doivent s’intégrer parfaitement pour
apporter une valeur maximale. C’est pourquoi nous avons élaboré des solutions « Full-Code » sur la
base d’une architecture microservices qui permet de tirer profit des méthodologies, architectures
et outils disponibles depuis l’avènement des solutions Cloud et DevOps.
Grâce aux bénéfices combinés de ces deux concepts, les inconvénients historiques de la
customisation par le développement ne sont plus d’actualité et il devient possible d’accroitre la
richesse fonctionnelle du système de l’entreprise à un rythme adapté à sa capacité, tout en
minimisant les risques.
En gagnant en sécurité, flexibilité et rapidité, nos développeurs et architectes peuvent alors se
concentrer exclusivement sur les enjeux métiers des applications et délivrer rapidement une plus-
value conséquente à nos clients.
Ce livre blanc présente les principes et la méthodologie retenus chez SpikeeLabs au travers d’un cas
concret d’intégration de notre solution de facturation BillingLabs.
Au-delà de la théorie, le lecteur y trouvera également la démonstration de l’efficacité de notre
approche à travers deux cas clients récents qui confirment l’amélioration d’indicateurs clés tels la
taille des équipes de support, le temps de cycle de développement ou encore les temps de
traitement.
Enfin, nous expliquerons comment le fonctionnement communautaire de logiciels
comme BillingLabs contribue aux enrichissements fonctionnels en continu. L’évolution du système
d’information ne doit plus être un frein au développement de l’entreprise et à son adaptation
constante aux besoins du marché. Notre mission chez SpikeeLabs est de rendre cela possible grâce
à l’utilisation des meilleures technologies et méthodologies adaptées.
Mes équipes et moi-même restons à votre disposition pour toute question.
Pierre LECOMTE, CEO de SpikeeLabs
3
LIVRE BLANC
Introduction
Dans toute entreprise, le SI est au cœur des processus métiers : toute action commerciale, marketing,
productive ou financière nécessite des outils parfaitement calibrés pour être exécutée. Ces outils sont très
souvent des produits sur étagère dont le fonctionnement, bien que configurable, n’est pas toujours adapté
aux processus métiers en place dans l’entreprise.
Lorsque l’entreprise est une start-up, le fonctionnement d’un produit permet un formatage des processus
de l’entreprise à l’outil. En revanche, lorsque celle-ci a grandi, cette approche ne suffit plus car elle impose
une configuration hautement spécifique. Et enfin, le temps que cette configuration finisse par être adaptée,
le métier de l’entreprise aura déjà évolué et nécessitera une nouvelle, longue et coûteuse adaptation de ce
produit.
Chez SpikeeLabs, nous avons la conviction qu’avec du logiciel sur mesure (“Full-Code”), les SI
peuvent se doter d’outils disposant des fonctionnalités les plus avancées, tout en étant parfaitement
adaptés au processus en place dans une entreprise. Si les technologies et méthodologies apportées par
les Cloud Providers et l’approche DevOps ont totalement bouleversé et optimisé la livraison d’applications,
elles permettent surtout d’avoir une équipe de développeurs dédiée aux besoins des utilisateurs et prête à
réagir à toute situation imprévue.
Nous sommes convaincus par cette double approche Full-Code / DevOps pour l’avoir déjà mise en œuvre
au travers de plusieurs de nos solutions : PaymentLabs, ProvisioningLab et surtout notre souche logicielle
de facturation « BillingLabs ». Au-delà des exigences fonctionnelles, chaque déploiement de BillingLabs
s’est inscrit dans une démarche de modernisation du SI avec des attentes fortes du client :
Avoir un SI évolutif : les nouvelles fonctionnalités doivent avoir un TTM* de quelques jours en
intégrant un flux permanent de déploiements.
Avoir une infrastructure optimisée : chaque composant de l’application doit pouvoir accéder à
des capacités de calcul suffisantes lorsqu’elles sont nécessaires, tout en évitant un
surdimensionnement des plateformes.
Avoir des applications hautement disponibles : le déploiement de nouvelles fonctionnalités ne
doit engendrer aucun downtime et les régressions fonctionnelles doivent être limitées au
maximum.
Nous avons pu répondre à ces exigences grâce à nos solutions reposant sur deux piliers principaux détaillés
au sein des chapitres de ce livre blanc :
Un socle logiciel ouvert et évolutif, permettant un démarrage rapide de l’application au sein d’un
nouveau SI mais offrant tous les outils aux développeurs pour implémenter de nouvelles
fonctionnalités. De plus, grâce à la communauté SpikeeLabs, toute évolution implémentée dans
BillingLabs est partagée et profite ainsi à l’ensemble des autres clients.
Une architecture scalable, qui s’appuie sur un ensemble de microservices dont la cohérence et le
fonctionnement global sont assurés par des technologies Cloud éprouvées. Ce sont ces mêmes
technologies qui permettent également de concevoir, développer, tester, déployer et scaler
indépendamment chacun de ces microservices.
4
LIVRE BLANC
Un code source ouvert et
évolutif
Dans notre cas d’usage, lorsque l’on monte une
solution complète de facturation pour un
nouveau client, le premier des défis consiste à
comprendre et adapter une solution existante
aux besoins des équipes de facturation et de
comptabilité.
Les workshops de compréhension du besoin
nous permettent d’obtenir deux documents
clés pour la définition de la solution :
Un modèle de données permettant de décrire
la hiérarchie des comptes clients, les
souscriptions, les offres et leurs frais associés,
les grilles tarifaires etc…
Une liste d’exigences fonctionnelles qui
décrit entre autres les fonctionnalités attendues
et les process de facturation à implémenter.
5
LIVRE BLANC
Le modèle de données métier sert alors de
spécification à l’implémentation des tables
utilisées en base de données : les objets utilisés
par l’application sont alors l’exacte réplique des
objets manipulés par les équipes métier. Les
équipes de développement, les équipes de
validation et les utilisateurs finaux parlent alors
le même langage dès les premières phases du
projet.
Pour accélérer cette mise en route du projet,
nous pouvons nous appuyer sur un socle
logiciel commun : toutes les API* existantes
dans la solution BillingLabs viennent avec des
modèles préconstruits. En effet, notre
expérience de la facturation nous a montré que
beaucoup de concepts sont universels lorsqu’il
s’agit de décrire un compte client, un compte
fournisseur, un frais récurrent etc…
Ces concepts sont d’ores et déjà implémentés
et peuvent être facilement étendus/modifiés
sans remettre en question tout le
fonctionnement du système.
6
LIVRE BLANC
La personnalisation rapide de ces modèles
permet d’obtenir une solution fonctionnelle
en quelques heures.
Toutes les API et les micro-services BillingLabs
sont alors prêts à fonctionner avec les objets
spécifiques au client. Seul un modèle basé sur
une communauté comme SpikeeLabs
permet cette rapidité et flexibilité : chacun
de nos nouveaux clients bénéficie d’un socle
éprouvé et sans cesse enrichi des
déploiements précédents tout en
conservant une totale liberté
d’implémentation. De plus, avec des API dont
les modèles héritent des objets métier du client,
l’intégration de celles-ci au sein du SI est
grandement facilitée car le langage sera unifié
au sein de toutes les applications.
Si la mise à disposition de toutes ces API
standards facilitent l’intégration, l’accès à
celles-ci doit impérativement être contrôlé et
maîtrisé, sans quoi la sécurisation des données
du SI serait compromise.
En s’appuyant sur une infrastructure réseau
Cloud, il est très facile de mettre en place une
topologie réseau sur-mesure. Elle permet
d’isoler certains accès, ou encore d’instancier
un API Manager qui va contrôler
l’authentification des utilisateurs/services se
connectant aux APIs et potentiellement faire du
rate-limiting sur les requêtes. Cet API Manager
peut être une solution managée par le Cloud
Provider ou une application déployée et
maintenue par l’intégrateur de la solution.
7LIVRE BLANC
Une fois tout ce socle en place, il faut alors Collection de tests unitaires automatisés
l’adapter pour intégrer toutes les couvrant 100% du code fonctionnel,
fonctionnalités et les process attendus par les permettant de garantir une qualité maximale
utilisateurs. En se basant sur une approche d’une release à une autre.
« Full-Code », les équipes de développement
peuvent s’approprier entièrement le Application Cloud-Native avec ressources
fonctionnement de la solution en développant Docker, Kubernetes et Helm préconfigurées,
au fur et à mesure ces fonctionnalités selon permettant d’avoir une application prête à être
l’organisation de leur choix : déployée dans n’importe quel environnement
cible.
Méthode agile SCRUM ou KANBAN suivant
la dynamique voulue par le client, afin de retirer
tout le bénéfice de cette approche : scalabilité
et TTM extrêmement rapide.
Cycle en V découpé par lots fonctionnels :
envisageable si le client n’est pas entré dans
une démarche Agile, le bénéfice sera alors
limité à la scalabilité.
Cette souplesse d’organisation n’est possible
qu’avec un code source ayant plusieurs
caractéristiques clés :
Structure en micro-services et micro-
frontend favorisant les évolutions simples. Les
process de validation de Merge-Request sont
plus rapides et moins stressants pour les
développeurs.
Utilisation de librairies partagées limitant la
redondance de code pour les concepts clés
(définition des modèles, moteur de workflow,
utilisation des bases NoSQL etc…)
8LIVRE BLANC
Les bénéfices d’une application ayant toutes Cette architecture offre un cadre structurant à
ces caractéristiques sont immédiats pour l’équipe de développement : elle sait en
l’équipe de développement : l’intégration d’une permanence quelles versions sont en
nouvelle release pour un microservice est développement, en recette ou en production.
soumise à l’ensemble des tests automatisés La solution s’étoffe alors en fonctionnalités
disponibles au sein de son repository. pour arriver au niveau d’exigence requis par
les utilisateurs finaux.
Si ceux-ci échouent ou si la couverture de code
est insuffisante, la release sera rejetée jusqu’à Une fois la première version stable atteinte, la
ce qu’une nouvelle version corrige les flexibilité de cette architecture permet de
problèmes. L’ajout de régression est alors maintenir un rythme de livraison soutenu avec
fortement limité et les nouvelles fonctionnalités un TTM extrêmement réduit.
doivent impérativement être testées avant tout Les phases de validation et mise en production
déploiement, même en environnement de étant lissées sur de plus grandes périodes, les
qualification. besoins en développeurs et infrastructure sont
constants et plus facile à planifier.
De plus, avec des releases plus fréquentes, le
scope associé est plus limité : le risque
d’impact sur le système est maitrisé et limité au
périmètre fonctionnel du microservice
concerné.
De plus, le déploiement d’une nouvelle version
de micro-services se fait automatiquement
depuis le gestionnaire de versions avec une
stratégie de rollout au choix : Canary
Deployment, Blue-Green Deployment etc…
Chaque environnement peut avoir sa propre
stratégie et nécessiter des approbations
manuelles si nécessaire.
9LIVRE BLANC
Une architecture scalable
L’intérêt d’une application purement logicielle Pour cette raison, il est important de stocker les
intégrant des solutions Cloud va plus loin que données dites « statiques » (peu d’écritures) au
l’agilité et la rapidité dans le processus de sein d’une base de données relationnelle
développement : elle permet également une offrant d’excellentes performances en lecture
flexibilité maximale sur le déploiement et pour le croisement de données : récupération
l’adaptation à la charge. des souscriptions d’un compte et leurs frais
associés, récupération des grilles tarifaires d’un
Dans une architecture micro-services comme fournisseur, etc…
celle de BillingLabs, les traitements « lourds »
vont être exécutés de manière asynchrone au
sein de workers*. Au sein de ces workers, les
écritures en base de données SQL vont être
limitées voir interdites, et chaque instance sera
invoquée pour travailler sur un contexte unique
(un compte client, une souscription etc…).
Ainsi, un microservice peut être virtuellement
instancié une infinité de fois sans avoir d’impact
sur la performance intrinsèque de chaque
instance, seule la capacité des bases de
données sera un facteur limitant.
10LIVRE BLANC
L’architecture microservice prend ici tout son Heureusement les API de ces composants
sens : en ayant des microservices indépendants, s’appuient sur une stack logicielle permettant
chacun d’eux est considéré comme MASTER sur d’automatiser cette synchronisation. En
les données qu’il va s’appuyant sur un service
manipuler et va alors gérer En s’appuyant sur du d’event-streaming, tel
sa propre base de données
Kafka pour les échanges qu’Apache Kafka, pour les
échanges entre toutes les
SQL. Ainsi, chacun de ces
composants peut être entre toutes les bases de bases de données, cette stack
« scalé » indépendamment données, cette stack « KafkaConnect » assure une
selon son volume de latence minimum entre une
données. « KafkaConnect » écriture sur une base MASTER
assure une latence et ses réplications sur toutes
Si l’entreprise possède un les bases SLAVE associées.
grand nombre de grilles minimum entre une
tarifaires, la base de écriture sur une base En complément de ces bases
données associée au de données relationnelles, les
composant de rating*
MASTER et ses volumes de données générés
pourra bénéficier réplications sur toutes par les différents workers sont
d’instances performantes. eux stockés au sein de bases
les bases SLAVE de données NoSQL dont la
Si l’entreprise ne facture associées. scalabilité native peut
que très peu d’usages mais accompagner très facilement
beaucoup de forfaits ou de une montée en charge
prestations unitaires, on soudaine ou progressive
allouera les instances SQL sans aucun problème.
performantes pour les
étages de charging et
invoicing plutôt que rating.
En multipliant les bases de
données relationnelles, la
synchronisation des
données entre toutes ces
bases devient très vite
complexe : chaque composant est MASTER sur
ses données mais peut-être SLAVE sur les
données d’un autre micro-service.
11LIVRE BLANC
Si les BDD managées par les providers de Quel que soit le fournisseur de l’environnement
Cloud permettent d’accompagner Kubernetes choisi par l’entreprise, les API à
facilement une montée en charge du utiliser pour le déploiement ainsi que la
système, l’application en elle-même doit description des ressources Kubernetes ne
pouvoir adapter le nombre de ses instances changent pas :
automatiquement et la CI/CD permettant le
rapidement. déploiement de la
solution est donc
Plusieurs écoles existent commune à l’ensemble
actuellement pour des projets BillingLabs et
déployer des applications ne nécessite que peu de
dans des environnements configuration spécifique
aussi « élastiques » : les (permissions, certificats
PaaS (type Heroku), les etc…)
FaaS ou encore les clusters
Kubernetes. De plus, la description des
ressources Kubernetes
Nous avons retenu cette inclut un certain nombre
dernière solution car elle offre l’énorme de métriques servant au scaling automatique :
avantage d’être agnostique à l’infrastructure ainsi chaque micro-service peut voir son
sous-jacente : elle peut être déployée dans un nombre d’instances s’adapter sans aucune
environnement AWS, GCP, Azure, Openstack intervention en fonction de la charge de chacun
ou encore bare-metal sans qu’aucune d’entre eux, de la charge des nœuds du cluster
modification ne soit nécessaire. ou encore de la charge des bases de données.
12LIVRE BLANC
Si la stratégie d’auto-scaling n’est pas En cas de problème critique (exemple :
satisfaisante, une simple modification du code datacenter indisponible), les solutions Cloud
source portant sur les métriques à surveiller permettent, entre autres, de monter une
permet d’ajuster celle-ci, nouvelle infrastructure
sans aucune intervention Une architecture complète en seulement
système/infra : l’équipe de quelques minutes, tout en
développement maitrise
logicielle adaptée disposant de données
totalement le comportement aux environnements « fraiches » grâce aux
de l’application sur tous les backups nativement offerts
environnements. De plus, en Cloud moderne offre par les Cloud Providers. Il
enrichissant cette chaine
d’outils avec un gestionnaire
les meilleurs outils est alors possible de refaire
un déploiement à partir des
d’infrastructures comme aux développeurs dernières releases de
Terraform, l’équipe de manière quasi-instantanée
développement est en d’applications : ceux- afin de retrouver une
mesure de piloter à 100% les ci peuvent alors se application disponible.
environnements de
déploiement. Énorme concentrer sur les Une architecture logicielle
avantage : l’ensemble des adaptée aux
opérations liées à ces besoins fonctionnels environnements Cloud
infrastructures est tracé et de leurs utilisateurs moderne offre les meilleurs
peut-être audité au sein outils aux développeurs
même des repository de afin de livrer un d’applications : ceux-ci
code source. peuvent alors se concentrer
service de qualité sur les besoins fonctionnels
Toutes ces solutions avec rapidité et de leurs utilisateurs afin de
viennent également sécuriser livrer un service de qualité
le cadre offert aux équipes de confiance. avec rapidité et confiance.
développement lorsque
survient un incident sur l’environnement de
production :
En cas d’anomalie à la suite d’une nouvelle
release, les procédures de rollback permettent
de revenir immédiatement à l’état précédent,
tant pour le(s) microservice(s) que pour la base
de données associée.
13LIVRE BLANC
Conclusion
Nous avons pu démontrer la pertinence de
notre approche « Full-Code » lors de deux
intégrations de BillingLabs au sein de SI
existants. Les processus de facturation en place
ont été intégrés très rapidement pour une plus-
value immédiate : les temps de traitements et
le nombre d’actions manuelles pour la
génération des factures étant réduits
considérablement dès la première release.
Nous avons alors pu continuer à enrichir la
2/3 semaines
TTM D’UNE NOUVELLE FONCTIONNALITE
solution en ajoutant des fonctionnalités sans
Vs plusieurs mois avec une approche classique
déstabiliser les utilisateurs : chaque
déploiement n’entrainait aucun downtime et
les nouvelles fonctionnalités faisaient l’objet de
8
présentation en amont auprès des utilisateurs
pour permettre une prise en main immédiate.
heures
Pour plus d’information sur les intégrations SI TRAITEMENT POUR 100 000 000 TRANSACTIONS
réalisées au cours de ces 2 projets, nous vous Vs plusieurs jours avec une approche classique
renvoyons vers le dernier chapitre de ce livre
blanc présentant des cas d’usage de BillingLabs
adaptés aux contextes de nos clients.
Cette démarche « Full-Code » peut s’appliquer
0 sec
DUREE D’INDISPONIBILITE PAR DEPLOIEMENT
à n’importe quelle application SI mais ses
Vs plusieurs heures avec une approche classique
bénéfices seront bien plus importants si
1/2
l’application est au cœur des process métiers
de l’entreprise : ceux-ci évoluant personnes
continuellement, il est primordial de pouvoir
accompagner ce changement constant avec TAILLE DE L’EQUIPE DE MAINTENANCE
fiabilité et sécurité. Et lorsque cette démarche Vs 4 à 5 personnes avec une approche classique
s’appuie sur une solution communautaire
comme celles développées par SpikeeLabs,
vous bénéficiez immédiatement d’un socle
applicatif robuste, avec toutes les
fonctionnalités standards attendues et les
fondations requises pour des évolutions
Au cours de ces deux projets, nous avons
maîtrisées.
pu constater l’amélioration d’indicateurs
clés qui illustrent bien l’apport de
l’approche BillingLabs en comparaison
d’une approche classique sur ce type de
14 système.LIVRE BLANC
Usecases d’intégration
Prise de commande Statistiques/BI sur les factures
Le module de charging de BillingLabs offre une Lorsque les factures sont générées par le
API permettant à un système externe de venir système, celles-ci sont disponibles au format
créer des nouvelles souscriptions, mettre à PDF pour être transmises au client, mais sont
jour ou terminer des souscriptions existantes. également stockées en base de données
En exploitant cette API, on s’assure d’avoir une et accessibles par le biais d’une API
solution de billing continuellement à jour avec dédiée permettant de récupérer n’importe
les souscriptions réalisées par le biais quelle facture et son contenu intégral. Les
d’un CustomerCare, d’un SelfCare, d’une données contenues dans les factures peuvent
boutique en ligne etc… L’intégration de cette alors être exploitées pour réaliser des
API peut se faire à différents niveaux : statistiques sur les montants facturés, les
produits souscrits, le nombre de souscriptions
Provisioning de chaque frais unitairement : c’est par client, les durées de souscriptions, etc…
l’outil de prise de commande qui maitrise alors
tout ou partie de la grille tarifaire. Export comptabilité
Une fois générée et transmise au client, la
Provisioning de souscription liée à une offre : facture doit également être partagée avec la
c’est BillingLabs qui a alors la maitrise comptabilité. Pour cela, les API vont
complète du catalogue d’offres. L’API du permettre à un système externe de récupérer
catalogue permet également la génération les informations de comptabilité détaillées
d’un devis associé à une offre et personnalisé (produit, tva, analytique etc…). Cette
avec les paramètres saisis par l’utilisateur. Non récupération peut être réalisée au sein du
seulement ce devis sera stocké dans un format logiciel de comptabilité ou par une médiation
technique au sein du composant afin d’être dédiée.
réutilisé par tout système du SI, mais il sera
également généré au format PDF, en suivant
l’identité visuelle de l’entreprise pour une
cohérence parfaite entre les devis et
les factures générés.
Pour compléter le process, ces devis peuvent
suivre un process de signature au sein
de BillingLabs : ils sont alors automatiquement
transformés en souscription en retrouvant tous
les paramètres associés à ce devis.
15LIVRE BLANC
Glossaire
API
Composant logiciel permettant de consulter/modifier les ressources manipulées au sein d’une
application par le biais de requêtes synchrones.
CHARGING
Processus de facturation permettant de générer des transactions liées à des frais, récurrents ou
ponctuels (exemple : abonnement mensuel de téléphonie mobile)
FULL-CODE
Solution dont les fonctionnalités sont créées et adaptées par la modification de code source
uniquement, afin d’être le plus proche possible du métier de l’utilisateur.
INVOICING
Processus de facturation permettant de générer une facture détaillée à partir d’un ensemble de
transactions, de la taxation associée et des informations des comptes débiteur et créditeur.
NO-CODE
Solution dont les fonctionnalités sont adaptables uniquement par de la configuration, ainsi que des
outils ne nécessitant aucune équipe de développement.
RATING
Processus de facturation permettant d’associer un cout à une transaction (consommation, évènement
etc…)
SCALING
Adaptation des ressources allouées à une application en fonction de différentes métriques.
Un scaling peut se faire de deux manières :
Horizontal en augmentant/diminuant le nombre le nombre de ressources infra (VM), chacune
exécutant une instance de l’application.
Vertical en augmentant/diminuant le nombre de ressources (CPU Core, RAM, etc…) d’une
instance de l’application.
TTM
Time To Market. Rapidité avec laquelle une équipe de développement est capable de transformer une
idée en fonctionnalité dans une application.
WORKER
Composant logiciel permettant d’appliquer des traitements métiers sur les données de l’application. Il
peut être déclenché manuellement ou automatiquement au sein d’un workflow et va produire un
résultat de manière asynchrone.
16LIVRE BLANC
Rédaction
Vincent ROHOU
Architecte logiciel, Vincent travaille sur des
solutions à destination des opérateurs
Télécom, il a participé à des projets
d’intégrations de BillingLabs en tant que chef
de projet et architecte.
Il a notamment contribué à l’intégration
complète de BillingLabs au sein
d’environnements Cloud avec des solutions
DevOps pour réduire au maximum les délais de
déploiements de ses composants.
Bruno LE FELLIC
Co-fondateur de SpikeeLabs, ses fortes
compétences techniques font de lui un expert
qualifié sur les architectures microservice et
leurs implémentations, sur le billing et
les CRM. C’est un spécialiste des domaines liés
au Big Data et l’IoT.
2021. Copyright©SpikeeLabs.
35, boulevard Solferino 35000 Rennes
www.spikeelabs.fr
17Vous pouvez aussi lire
