La vision des OCTOs pour les 5 à 10 prochaines années

En ce début d’année 2018, nous avons demandé à quelques Octos comment ils prévoient l’évolution de leur métier, des technologies, les ruptures, les nouvelles approches, etc. C’est un exercice de style qui ne prétend pas nécessairement dire le vrai, mais qui a le mérite de présenter certaines convictions et d’inviter au débat. Partagez avec nous vos réactions et analyses, en réagissant à cet article !

Les plateformes cloud comme nouveaux runtimes

Variables, disques et machines seront dépassés comme l’ont été les pointeurs, bandes et architectures processeurs.

Dans 10 ans les applications se partageront en deux catégories : les applications multi-devices en JavaScript et les applications encapsulées dans des conteneurs.

La notion de serveur physique aura disparu : l’ensemble des progiciels et ressources informatiques seront facturées à la consommation et la notion de cloud et de localisation des données ne seront qu’une option de négociation du contrat d’hébergement.

Les notions d’OS et de disque physique seront considérées comme legacy. Elle n’existeront plus que masquées à l’intérieur des conteneurs. Les nouvelles plateformes applicatives auront abstrait les notions de mémoire et de disque dur. Le développeur ne manipulera plus qu’un ensemble de ressources dans un format de stockage identique sur tous les niveaux de cache.

Le code indiquera comment transformer ces données – la notion de donnée mutable aura disparu – et la plateforme se chargera de positionner le code et les données sur le niveau de cache le plus opportun (RAM, NVRAM, SSD local ou leurs équivalents distants).

La notion de variable aura disparu comme les structures de données ont disparu en leur temps au profit des objets. Toutes les données seront masquées derrière des promesses et la plateforme ordonnera la résolution de ces promesses en organisant un plan d’exécution de traitement optimisé à l’aide de machine learning.

Marc Bojoly – Architecte Senior Cloud Native Applications

Les interfaces naturelles et la délégation de responsabilité

Tous les objets sont connectés/connectables, même moi.

L’IA est sur le cloud mais aussi dans les objets (Edge computing) avec du MachineLearning/DeepLearning directement exploité par le silicium. Cela me donne accès à des nouveaux modes d’interactions avec un internet pervasif, omniprésent, prédictif. Une partie de mes activités de gestion quotidienne (achat, réapprovisionnement, domotique, choix) n’est plus gérée en explicite/déclaratif mais inférée par le système.

J’ai opté pour ne plus être maître de mon frigo, il est dans un éco-système autonome constitué notamment d’une boucle de monitoring / approvisionnement assisté par ma balance connectée, mon four connecté, mon bracelet sportif, mon dossier médical électronique et bien sûr de mes marques et fournisseurs préférés (Amazon, cmescourses…)

J’étend petit à petit mon abonnement Prime illimité pour tout mon approvisionnement et la recommandation en terme de nourriture, consommables, loisirs, sorties.

Au niveau des interactions, tout est multimodal: Visuel, Tactile, Vocal, Gestuel. Je parle à chacune de mes lampes, radiateurs, je parle à mon four. En fait, je ne sais pas si je parle à une seule entité de gestion ou si chaque appareil est autonome, mais je n’en ai finalement pas grand chose à faire. It just works !

Mais une scission dans les usages/utilisateurs apparaît : les ultra connectés/geeks et les retro/natures/bio de l’autre. Je me rend compte que je partage moins et communique moins avec mes amis déconnectés qui ne font pas partie mon nouveau réseau social. Cela soulève des questions sociales et éthiques que les organismes de régulation et groupements politiques s’empressent d’aborder.

J’ai vu une publicité pour ces nouveaux implants grand public pour gérer le cholestérol, c’est pas mal mais il faut déjà que je choisisse mon implant Media, j’hésite entre la puce Disney d’Apple ou celle Netflix d’Amazon…

Vincent Guigui – Innovative Technology Advisor

Après l’expansion, la concentration des services

Après une multiplication des services et des serveurs, nous retournerons vers une concentration, afin de réduire la complexité.

Actuellement, nous allons vers une décomposition en services, exécutés par de plus en plus de serveurs. Cela génère des flux de communication nombreux et redondants. En multipliant les serveurs, on augmente les probabilités de pannes.

Une des causes de cette évolution est la nécessité, à partir d’un certain volume de données, de distribuer les traitements. Cela nécessite d’utiliser de nouvelles technologies s’appuyant sur la distribution (NoSQL, Kafka, etc.). Mais, c’est au prix d’une perte des transactions, entraîne généralement une cohérence différée, à terme, et d’autres difficultés (idempotence, etc). Les coûts dérivés de ces technologies sont très importants (gestion de nombreux serveurs, code plus complexe, etc.). Il faut alors s’interroger sur la pertinence d’utiliser ces nouvelles technologies. Est-ce que le volume à traiter nécessite véritablement d’ajouter de nombreuses contraintes au SI et aux traitements des données ?

D’ici 5 à 10 ans, je prévois un retournement de tendance, avec une concentration des traitements dans de moins en moins de serveurs. En effet, le seuil à partir duquel il sera nécessaire de distribuer les traitements sera bien plus élevé, et probablement supérieur aux besoins de la grande majorité des entreprises. Nous pourrons pousser bien plus loin les technologies “anciennes”, sans devoir distribuer les traitements et, de ce fait, sans perdre tous les avantages d’un modèle centralisé type SQL.

Cela sera possible par la présence de CPU avec plusieurs dizaines de cœurs et par l’utilisation massive de RAM non volatile (NVRAM), servant de persistance des données tout-en-RAM. Avec plusieurs téraoctets adressables en RAM, il n’y aura d’I/O que pour communiquer avec le client via le réseau. Les serveurs d’applications traiteront les requêtes au plus vite, directement et uniquement en mémoire (clean architecture). La CPU sera utilisée au maximum, permettant de réduire drastiquement le nombre de serveurs. On peut déjà sentir cela avec des approches comme Scylladb qui permet de remplacer 10 nœuds Cassandra par un seul. Le code sera plus simple, débarrassé des conversions et sérialisations inutiles et se focalisera sur la structuration efficace en mémoire (h-table, pointeurs, etc.) ainsi que sur les règles métiers.

Philippe Prados – Architecte Senior Big Data

Un nouveau paradigme d’automatisation dans le système d’information

L’intelligence artificielle va changer la façon dont nous exerçons nos métiers de l’IT

Dans 10 ans, le monde actuel autour d’Hadoop correspondra à l’image que l’on a de nos mainframes : un legacy chers, rigides, et difficiles à faire évoluer. La faute nous reviendra, car nous seront responsables d’avoir développé dessus autant d’applications inadaptées, pour rentabiliser un investissement fait avant d’en avoir les besoins…

En parallèle, nous allons nous rendre compte assez rapidement que le machine learning, l’IA, la datascience, ce n’est que de l’IT.

Puis le machine learning va petit à petit s’installer dans nos métiers, comme nouvel outil d’automatisation de tâches (en complément de la programmation). Les travaux récents de Google et des géants vont dans ce sens :

  • Les experts vont devoir maîtriser de nouveaux outils. Un exemple récent avec les Learned Index : Indexation dans les bases de données à base de machine learning (Learned index structure). Au lieu d’utiliser une structure classique et polyvalente comme le BTree (très largement utilisé dans les SGBD actuels), Google laisse un algorithme découvrir la structure la plus optimale à utiliser pour stocker la donnée qui lui est fournie. Un modèle détecte plus facilement qu’un humain quelle est la répartition de la donnée (skew ?), inférer l’ordre (potentiellement irrégulier).
  • Le machine learning n’est plus seulement dans les mains des datascientists, mais de n’importe qui (ex : NanoNet). Tout le monde devra savoir l’utiliser, savoir définir ses paramètres, savoir définir une métrique au sens métier, comment calculer son erreur, etc.. Google Vizier est un service largement déployé chez Google qui s’adresse plutôt aux analystes, aux PM (programme manager) et aux développeurs, afin d’aider à optimiser des algorithmes « boîtes noires » à partir d’une métrique métier, et de suivre l’évolution de cette métrique. Google met dans les mains d’experts métier un outil jusqu’alors très technique. Ils ont démontré l’efficacité du service en améliorant une recette de cookies, en prouvant que c’est applicable à n’importe quel processus métier.
  • Le management opérationnel des plateformes / stack techniques aussi complexes nous amène beaucoup de technologies à faire interagir de façon performante. La combinatoire entre tous les paramètres est trop élevée pour en connaitre le résultat à l’avance, les méthodes actuelles des experts pour optimiser ces systèmes sont empiriques (test & learn). Une approche datascience accélère énormément cette phase empirique (Automatic Database Management System Tuning Through Large-scale Machine Learning) et donne une aide aux Ops et DBAs très pertinente. Avec des systèmes autogérés (Peloton DB, une base de donnée autogérée qui converge vers un état optimale), peut être verrons-nous les astreintes diminuer ?
  • Le machine learning appliqué au génie logiciel : aider à extraire l’essence d’un comportement dans un système complexe. Nous commencerons probablement par la génération de code à tout-va, puis nous reviendrons en arrière en se disant que ce n’est pas pour tout. Enfin, grâce à l’expérience précédente, nous évoluerons vers de l’assistanat pour des choses spécifiques (code boiler plate, compilation, DSL, garbage collector, optimizer, profiler, etc…)

A l’image de Google actuellement (ils ont toujours de l’avance), nous ne feront pas tout par du machine learning, mais nous ferons tout avec l’assistance du machine learning. Ce sera donc de nouvelles méthodes à découvrir (qui remplaceront peut être SCRUM & cie), saupoudré d’un peu de technique.

Pour en revenir à “L’intelligence artificielle va transformer la façon dont nous exerçons nos métiers de l’IT”, et ce qui nous attend, nous à la DSI, ou en consultants, ou encore en métiers (etc) :

  • L’exemple de Jeffrey Dean (un des principaux architectes de Google MapReduce, BigTable, Protobuf, TensorFlow), qui évolue au sein de Google depuis 99. Il a commencé par faire beaucoup de développement sur des systèmes opérationnels (le search, les ads) et de l’expertise très technique (mapreduce, bigtable). Vers 2010, il travaille de plus en plus avec du machine learning dans les nouvelles architectures (construction de la principale plateforme de datascience, TensorFlow). Il a su se transformer.
  • Un contre exemple chez Google et Amit Singhal qui a quitté il y a deux ans son poste de Head of Search (=poussé dehors ?), parce qu’il n’a pas cru pendant trop longtemps à l’incorporation du machine learning dans la décision des résultats de recherche. Ceci est un exemple de quelqu’un qui s’est laissé dépasser chez Google.

C’est la réalité de nos 10-15 prochaines années, comme le web l’a été ces 15/20 dernières années. Le web nous a poussé à adapter nos pratiques, nos architectures, nos outils.

Benjamin Joyen-Conseil – Consultant

Le monde sera le datacenter où s’exécutent des chorégraphies d’applications autonomes

Base de donnés distribuées NoSQL, CaaS, mondialisation des datacenters cloud : Et si ceci n’était que les prémices d’une nouvelle façon de gérer les applications ?

Depuis le début des années 2000 nous assistons à l’avènement des applications distribuées. D’abord déployées au sein d’un même datacenter, puis à présent de manière courante sur plusieurs data-centers. En terme d’architecture, cela se traduit par une transition depuis des patterns essentiellement monolithiques vers un ensemble de patterns orientés services (Réf: Microservices: a definition of this new architectural term par Martin Fowler).

L’arrivée du Cloud dans le paysage a notamment accéléré cette transition. Ce changement de paradigme a fait naître de nouveaux besoins de contrôles des services. En ce sens, le cycle de vie d’une application est le fruit de l’orchestration des cycles de vie des différents services. On peut citer par exemple l’attrait pour des outils tels qu’Ansible ou Terraform qui sont, par essence, des orchestrateurs de services (cf Google trends).

Ces principes d’orchestration se basent en général sur des notions d’états des systèmes. Leur efficacité repose quant-à elle sur le fait que le nombre de « degrés de liberté » est fini.

La généralisation des API publiques et la « cloudification » des applications va rendre l’orchestration de ces services de plus en plus complexe. Évaluer l’état d’un système va se révéler aussi compliqué que de prédire le temps qu’il fera demain.

Or, comme le rappelle Mark Burgess dans son livre « In search of certainty », la météorologie est un phénomène particulièrement difficile à prédire mais représentatif de systèmes complexes à grande échelle : les multiples interactions entre les éléments augmentent les degrés de liberté. Ces interactions sont à l’origine de non-linéarités et, par conséquent, en rendent la modélisation difficile (en référence aux travaux d’Edward Lorenz).

Il sera de moins en moins possible d’écrire un système de gestion déterministe et centralisé du fait de l’augmentation du nombre possible d’états de l’application dans son ensemble. Les systèmes pourront néanmoins se baser sur l’apprentissage de type « deep learning » qui, par essence, apprend à réagir face aux systèmes non-linéaires.

Enfin, il y a fort à parier qu’un organe central de contrôle ne sera plus apte à gérer ces changements. Par exemple, la latence réseau, importante entre plusieurs datacenters, induit souvent un décalage et un déphasage entre l’état observé et l’état réel des services managés. Depuis plusieurs années de nombreux paradigmes d’architecture se mettent en place pour pallier à ces problèmes (le « sharding » des bases de données NoSQL en est un bon exemple).

Donc, a l’instar des applications de type « blockchain », on assiste de plus en plus à une décentralisation des organes de contrôles (etcd, consul et autres sont de bons exemples de systèmes de gestion d’éléments de contrôles décentralisés).

En conséquence, je pense que l’application de demain sera probablement constituée d’un ensemble de services autonomes. Cet ensemble exécutera une chorégraphie. Elle sera le plan d’exécution des composants qui adapteront leur comportement, de manière intelligente, aux événements qu’elles rencontreront.

Ces évènements pourront être matérialisés sous forme de données dans un espace de tuples à l’échelle planétaire et fonctionnera, à la manière de la blockchain, sans organe de contrôle centralisé. Ce mode de fonctionnement permettra, entre autres, de réduire les risques liés d’incertitude, et donc d’augmenter la qualité sans faire exploser les coûts d’exploitation.

La hype informatique nommera peut être même ces architectures « Heisenberg-as-a-Service », qui sait ?

Olivier Wulveryck – Consultant DevOps – Octo Lille

L’inévitable expansion des blockchain publiques

Les réseaux sans entité centrale (trustless) de type blockchain vont devenir les fondations de notre société

Depuis maintenant quelques années, nous assistons à une multiplication des projets et acteurs dans l’écosystème blockchain.

Si les désirs initiaux étaient une monnaie sans entité centrale – Bitcoin – , beaucoup de projets essaient d’ajouter de la transparence dans la logique métier, de la résilience et de redonner du contrôle à l’utilisateur final.

Si on met de côté le brouhaha des nombreuses levées de fonds (ce qui rappelle les débuts d’Internet) qui se créent de façon déconcertante ; on retrouve dans ces projets une certaine essence qui provient de la plateforme sous-jacente : la blockchain publique.

Ce réseau a une spécificité : son aspect public et open-source. Il est en effet accessible par n’importe qui et la majorité des (futurs) projets qu’il fait tourner sont eux aussi publics et open-sources.

Les technologies de type permissioned, peuvent également être open-sources mais ne sont pas publiques. Elles sont en effet basées sur des PKI pour entrer dans le réseau, comme Corda ou Hyperledger Fabric.

L’éthique, la transparence et l’ouverture sont des notions centrales pour de nombreux projets et nous allons voir petit à petit ces valeurs s’ancrer dans des nouveaux services et faire évoluer les mentalités.

Aussi, les coûts d’opérations très bas et l’accessibilité sans cloisonnement géographique de ces plateformes vont permettent le développement d’une floppée de nouveaux business et de travaux collaboratifs. Par exemple Colony, pour des organisations ouvertes, ou Sovrin, pour une identité « auto-souveraine ».

Aujourd’hui, nous sommes encore aux prémices de ce changement de paradigme.

Les plateformes existantes qui permettent de construire ces projets ne sont pas encore matures. Par exemple, Ethereum a un débit de 15 transactions par secondes, aucune confidentialité, un consensus énergivore, des frais élevées…

On constate d’ailleurs une vraie course à la technologie, avec le développement un peu partout dans le monde de nouveaux protocoles trustless de type blockchain ou DAG (cf. Protocole Spectre / IOTA) et des consensus de plus en plus inventifs.

Dans les plateformes qui permettent d’exécuter de la logique, EOS et Cardano pourraient êtres, parmi d’autres, de possibles compétiteurs à Ethereum.

Se pose donc la question du devenir d’Ethereum, la blockchain d’exécution de code la plus populaire et en production depuis 2015. Avec une capitalisation du marché d’environ 95 milliards de dollars, son évolution est grandement ralentie ; toute erreur d’implémentation dans le protocole peut être fatale ou entraîner un énième hard-fork !

Un réseau de blockchain interopérables va progressivement se mettre en place, ce qui fait émerger quelques atouts :

  • Permettre d’avoir des réseaux spécialisés, car certains nécessitent de la confidentialité, d’autres de la régulation…
  • Résoudre les problèmes de scalabilité inhérent aux blockchains publiques

On retrouve d’ailleurs l’émergence de projets de plus en plus aboutis sur le sujet de l’interopérabilité, comme Polkadot, Cosmos, Interledger, etc.

Des plateformes prévoient également d’inclure directement des blockchain “filles” (du nom de sidechain) dans leurs réseau, pour atteindre sensiblement les mêmes buts. Voir les projets Liquid, Cardano, Plasma, Ardor, Lisk, etc.

Espérons que dans le futur, la maturité de ces plateformes permettent la faisabilité des nombreux cas d’usages actuellement à l’état de recherche ou de développement.

Loup Theron – Consultant

Des SI scalables aux SI intelligents ?

Les SI de demain subiront des disruptions profondes amenées par l’Intelligence Artificielle et le Quantum Computing

Métier / Marché

Pour parler spécifiquement du marché français des technologies Big Data, nous sommes actuellement dans la “Vallée de la Désillusion” telle que prédite par Gartner. Le mythe (performance + volume infini + iso-fonctionnalités) par rapport aux solutions standard tombe. Dans les années à venir, le métier du consulting informatique devra relever le défi suivant : faire maturer les clients sur les concepts clefs (pertinence et périmètre du Big Data, gouvernance, trajectoires réalistes) tout en les préparant aux futures disruptions évoquées dans cet article.

Les énormes éditeurs historiques trustant les SI du monde (IBM, Oracle, SAP, …) vont voir leur règne davantage entamé dans les années à venir. Même s’ils sont challengés par les éditeurs de plateformes et de stacks Open Source autour du Big Data et du cloud, l’érosion promise de leur marché n’a pas vraiment eu lieu. L’évidence est que ces nouveaux éditeurs deviennent stratégiques pour les SI (⅔ des clients considèrent déjà Hadoop comme stratégique, Amazon est lead du marché du cloud, …). La stratégie des éditeurs historiques sera de tenter d’influencer les solutions Open Source (par investissements et partenariats) plutôt que d’opposer des solutions propriétaires. Ce qui est déjà amorcé par IBM avec Hortonworks et Intel avec Cloudera.

Technologies

Je suis aligné avec les points de vue de Philippe, Vincent, Marc et Benjamin. Plus globalement, nous nous dirigeons vers l’émergence de “SI Intelligents”, capables de comportements auto-adaptés et prédictifs, continuellement optimisés. Ils exploiteront la masse de signaux faibles qu’ils captent et génèrent eux-mêmes (remontées des sous-systèmes, monitoring, traffic, volumétrie, …) pour prédire leur état futur et adapteront leur comportement en conséquence.

L’adaptation des technologies hardware pour intégrer de l’IA a déjà commencé. En témoigne l’émergence de microprocesseurs dédiées spécifiquement à reproduire le comportement de neurones réels, jusqu’à abandonner l’architecture de Von Neumann pour passer à une base photonique ou encore à des architectures orientées graphe. Sont apparus parallèlement des chips architecturés pour les algorithmes d’IA de deep learning, permettant une exécution plus efficace, plus rapide, moins gourmande.

Également, pour améliorer le contrôle et l’efficacité des briques architecturales, on assiste déjà à l’apparition de Machine Learning dans des stack clefs tel que les Load Balancers et les Firewalls. Ces initiatives ont toutes les chances de se généraliser dans les années à venir. L’étape suivante viendra par leur implantation au niveau même du contrôle macroscopique du comportement du SI.

Un autre axe technologique devrait, dans les années à venir, revêtir une importance grandissante. La blockchain (lire “L’inévitable expansion des blockchain publiques”) deviendra un enjeu au niveau intra et inter états, et s’installera peu à peu comme un outil central de référence. Des tensions sont donc à prévoir en raison du fatal overlap des intérêts. Comme exemples de frémissement : les considérations grandissantes sur les monnaies virtuelles (interdiction, régulation) et les systèmes globaux de blockchain financiers, avec l’apparition de premières considérations sur le risque de singularité cryptomonétaire.

Ruptures / nouvelles approches

A en croire cet article, en 2040, la terre ne pourra plus produire assez d’énergie pour faire tourner toutes les CPUs existantes. Volontairement alarmiste, cette annonce a pour le moins le mérite de nous questionner sur les pistes qui permettraient d’éviter cette issue dramatique. L’une d’elles viendrait du quantum computing, qui promet, à terme, une puissance de calcul phénoménale pour un coût énergétique promis très en deçà de son équivalent standard. Ce ne serait plus seulement une rupture technologique de puissance de calcul : le calcul quantique en deviendrait un enjeu de survie de l’humanité.

Le quantum computing devrait faire des progrès géantissimes en termes d’industrialisation car la concurrence s’installe entre les géants Intel, Google, NASA, IBM. En quelques années, une fois que des solutions viables liées aux problématiques de cohérence de qubits et de bruit quantique seront trouvées, la miniaturisation devrait rapidement s’amorcer et une puissance phénoménale de calcul montrera son nez dans les data centers. Aujourd’hui déjà, Google et IBM, annoncent  (indépendamment) des calculateurs quantiques 10 millions de fois plus puissants qu’un PC avec « seulement » une cinquantaine de qubits.

L’IA à base de quantum computing, c’est la rupture suivante. La puissance de calcul et les évolutions des concepts et algorithmes d’IA alliés marqueront le tournant du siècle en informatique. Dans 10 ans le monde aura probablement changé.

Dans un horizon de quelques années, nous verrons probablement apparaître une offre de service de calcul quantique orientée IA. On peut imaginer de certainement rares entreprises maîtrisant la mise en oeuvre de calculateurs quantiques proposer par exemple, dans une optique de rentabilisation, le calcul des optimums tensoriels d’un algorithme de ML fourni par le client via une API dans une zone sécurisée… par des algorithmes de cryptographie eux-mêmes “quantum-resistant”, car existe déjà une liste d’algorithmes crackables / non crackables par des attaques quantiques…

Poussons plus loin (le rêve ?). Avec des approches globalistes, les systèmes d’IA pourront un jour exhiber des états macroscopiques, via des progrès sur la causalité émergente, abstrayant la complexité des états sous-jacents, et plus puissants causalement que la somme de leurs sous-systèmes, ces derniers étant également des IA. Dans le même esprit que la tendance vers un datacenter mondial chorégraphique (tel que dans l’article d’Olivier Wulveryck), on imagine un méta-comportement au niveau des SI Intelligents, où, tout comme des swarm robots, des essaims de subdivisions de SI s’organiseront, en profitant au mieux de la vision locale de chacun d’eux, pour décider d’actions d’optimisation partagées en vue de l’efficience globale du SI.

Mais je crois qu’on dépasse l’horizon des 10 ans… non ?

Yacine Benabderrahmane – Architecte Senior Big Data

3 commentaires sur “La vision des OCTOs pour les 5 à 10 prochaines années”

  • Merci pour cette article très intéressant, et comme d'habitude fidèle a l'image d'OCTO.
  • Tres interessant. J'espere que la vision de Vincent Guigui est un troll... dystopique. Il faut se demander si c'est le monde que nous voulons, bien qu'il soit probablement inevitable(?)
  • L'extrait ci-dessous aurait mérité un peu de vulgarisation :-) [...] Avec des approches globalistes, les systèmes d’IA pourront un jour exhiber des états macroscopiques, via des progrès sur la causalité émergente, abstrayant la complexité des états sous-jacents, et plus puissants causalement que la somme de leurs sous-systèmes, ces derniers étant également des IA. Dans le même esprit que la tendance vers un datacenter mondial chorégraphique (tel que dans l’article d’Olivier Wulveryck), on imagine un méta-comportement au niveau des SI Intelligents, où, tout comme des swarm robots, des essaims de subdivisions de SI s’organiseront, en profitant au mieux de la vision locale de chacun d’eux, pour décider d’actions d’optimisation partagées en vue de l’efficience globale du SI. [...]
    1. Laisser un commentaire

      Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


      Ce formulaire est protégé par Google Recaptcha