Les fonds FEILT, une variante des FIA

Fatimata

L’industrie de la gestion collective s’est enrichie de l’application du règlement ELTIF (European long term investment fund) ou FEILT (fonds européen d’investissement à long terme).
Il y avait les fonds UCIT IV, relevant de la directive européenne Undertaking for the collective investment in transferable securities, et les FIA (fonds d’investissement alternatifs), relevant de la directive Alternative Investment Fund Managers. L’appellation OPC (organisme de placement collectif) désigne les OPCVM (OPC en valeurs mobilières) et les FIA, dont les FEILT sont désormais une variante. Ces fonds ont pour objectif d’apporter des financements de longue durée à des projets d’infrastructure (actifs physiques), à des sociétés non cotées ou à des PME cotées qui émettent des instruments de capitaux propres ou de dette. Compte tenu de l’importance des financements à long terme pour la croissance dans l’Union européenne, le règlement ELTIF vise à acheminer l’épargne vers des investissements dans l’économie réelle.

Les fonds européens d’investissement de long terme ont été introduits par le règlement européen qui est entré en application le 9 décembre 2015. L’AMF vient de délivrer les deux premiers agréments ELTIF à deux fonds ayant le statut de sociétés de libre partenariat.

Désormais il est possible d’investir dans un fond FEILT en France et ainsi profiter de ce label mais ce uniquement pour les investisseurs professionnels, et au travers de la structure juridique SLP (‘‘Société de Libre Partenariat’’), que l’AMF commence par ailleurs à agréer régulièrement.
Quels sont les apport de ce nouveau type de fonds?

Les FEILT fixent un cadre juridique permettant d’attirer l’épargne et de transférer des capitaux importants vers des secteurs nécessitant des investissements à long terme. Ces fonds se veulent être un financement alternatif ou complémentaire au crédit bancaire qui s’est rarifié suite à la crise économique.
D’une part, le cadre juridique de ce nouveau véhicule a pour but de générer des revenus réguliers pour les organismes de gestion de retraite, les fonds de pension, les entreprises d’assurance, les fondations et plus généralement les investisseurs recherchant des rendements long terme. D’autre part, il a vocation à offrir à ces investisseurs professionnels l’opportunité d’apporter des financements à des projets d’infrastructure, à des PME non cotées et à des PME cotées rencontrant des difficultés pour se financer sur le marché.
Avec la Directive AIFM qui limite la commercialisation des FIA aux investisseurs professionnels, ce Règlement comporte un atout majeur pour les gestionnaires AIFM car il leur permet de commercialiser leurs FIA à des investisseurs de détail dans toute l’Union européenne. La principale innovation de ce Règlement est la création d’un « Passeport retail de FIA ».

Nous attendons donc avec impatience la déclinaison du concept ELTIF sur les autres places financières européennes, en particulier au Luxembourg et en Irlande, qui avaient modifié très vite leur cadre réglementaire pour accueillir les ELTIF, et à Londres, où la FCA – Financial Conduct Authority – planche sur les ELTIF à destination des investisseurs particuliers.

facebooktwittergoogle_plusmail

Introduction à Ansible

jacques

Tout développeur qu’il soit, a pu, un jour, rencontrer des tâches d’administration système, allant de la simple configuration d’un outil ou d’un serveur jusqu’au déploiement de tout en environnement pour les plus veinards.

Lorsque la tâche devient répétitive et rébarbative, on a tendance à se reposer sur des méthodes automatisées tels que des scripts concoctés par le plus grand chef, à savoir vous.

Ces méthodes peuvent convenir pour des actions simples et rapides mais lorsque l’on doit monter  tout un système sur un ou plusieurs environnements, là cela peut devenir douloureux.

C’est dans ce contexte que l’on a pu voir émerger des Outils de Gestion de Configuration (ou Configuration Management Tool) ces dernières années afin de faciliter l’automatisation de procédures d’exploitation usante.

L’un de ces outils que je souhaiterais vous présenter issu de cette philosophie se nomme Ansible.

Qu’est-ce que ANSIBLE ?

Ansible est un logiciel open-source (Licence sous GNU GPL), écrit en Python, qui offre la possibilité de déployer des outils, d’exécuter des tâches, de gérer la configuration d’outils sur vos environnements préférés à distance.

 

Mais que permet de faire ANSIBLE ?

Comme la plupart des Outils de Gestion de Configuration, il nous facilite la vie en réalisant à distance des traitements comme :

  • La configuration d’environnement ou d’outils
  • Les montées de versions de produit installé en environnement
  • L’installation de nouveaux outils
  • La remontée de tout un environnement (ce qui combine les trois points précédents)
  • et le plus important, le Café (pour peu que l’on ait une cafetière connectée)

Mise en place

Nos amis issus du monde Microsoft, pourrait être déçus car Ansible ne permet pas d’être installé sur leur précieux environnement Windows.

Au delà de ça, le produit ne nécessite quasiment rien. Une installation sur un serveur hôte suffit.

Seul pré-requis pour l’atout de ce produit, vos environnements distants doivent être accessibles par le protocole SSH ce qui suppose l’installation d’un système d’exploitation en amont.

Sachez toutefois que même si Ansible n’est pas déployable sur un Windows hôte, il permet néanmoins leur administration sur des serveurs distants.

 

 

Comment ça marche ?

Une fois l’installation réalisée sur le serveur hôte, tout le travail à réaliser est sur l’ordonnancement des tâches à effectuer.

Pour une telle entreprise, Ansible nous offre la possibilité d’écrire des “playbooks”, une arborescence comprenant :

  • Des scripts, décrivant nos tâches à réaliser, écrit en YAML.

Exemple de playbook pour installer Java :

 

  • Des templates, à transmettre et comprenant la configuration qui sera pré-rempli pour vos outils préférés, écrit en JINJA2.

Exemple de fichier template en JINJA2 : Fichier de description des utilisateurs à une application Tomcat.

 

Pour nous aider à écrire nos scripts, Ansible nous offre pas moins de 450 modules différents et une communauté active.

De plus, afin de voir des exemples de playbooks, Ansible  nous en fournit également un certain nombre sur GitHub.

Ansible Front-End

Ansible est un produit libre, mais tel quel, il n’est exploitable que par son mode console ce qui n’est pas très User-Friendly.

Mais, Ansible, nous propose son IHM Ansible Tower qui pourra permettre d’auditer, configurer et gérer vos déploiements mais malheureusement pour les petites bourses, il est payant.

Ansible_Tower_blog

 

Pas de panique, il existe des solutions alternatives. En effet, une de ces solutions est de pouvoir utiliser Foreman comme front avec le plugin de connexion Ansible.

La procédure d’installation s’effectue de la manière suivante :

  • Installer Foreman sur le même serveur hôte qu’Ansible
  • Installer le plugin Ansible pour Foreman
  • Installer une fonction python de callback qui fournira à Ansible un certain nombre d’information

Foreman_Ansible

Seul cheveux dans la soupe, Foreman est installé avec Puppet par défaut (Puppet étant un des produits alternatifs d’Ansible).

A moins de connaître la méthode d’installation depuis les sources de Foreman sans Puppet, le moyen le plus simple d’avoir une installation finale sans Puppet est de permettre l’installation de Foreman par la voie standard avant de retirer tous les paquets liés à Puppet.

 

facebooktwittergoogle_plusmail

Introduction à DOCKER

Vivien

Vous en avez probablement déjà entendu parler. Mais connaissez vous DOCKER ?

Docker s’inscrit dans cette nouvelle mode qu’est le devops. Comment faire pour aller plus vite et travailler plus efficacement ? Docker vous apporte des éléments de réponses.

Docker consiste à faire tourner des “containers” qui embarquent un logiciel pouvant fonctionner en toute autonomie. Le container contiendra tout ce dont il a besoin pour faire correctement fonctionner votre application. Comme si elle tournait sur votre poste ou un serveur.

Docker s’appuie sur le Kernel et l’OS de la machine sur lequel vous l’avez installé :

Capture d'écran 2016-05-26 14.34.08

Pour créer un container, vous devez écrire un fichier qui spécifiera les étapes d’installations => De quoi à besoin votre application pour fonctionner. L’intérêt est ensuite multiple :

– Possibilité de lancer votre container sur n’importe quelle machine ayant un docker   d’installé. Donc plus de problème de livraison. Une fois testé, vous pouvez fournir votre container et pas de surprise par la suite.

– Les containers sont des “sandbox” donc ne communique pas directement avec l’extérieur. Cela apporte un niveau de sécurité quand vous travaillez sur des applications sensibles.

– Vous avez accès à une application “jetable”. Au moindre problème, vous pouvez supprimer le container et en relancer un qui sera “neuf”.

Pour aller plus loin, n’hésiter pas à aller fouiller sur le site officiel de DOCKER :) https://www.docker.com/

facebooktwittergoogle_plusmail

Introduction au système CLS et au Risque de règlement dans les opérations de change

Hayette

Le système CLS « Countinuous Linked Settlement » à été mis en place le 9 septembre 2002 suite aux recommandations émises par les banques centrales des pays du G10 afin de réduire le risque de règlement dans les opérations de change en appliquant le principe du «paiement contre paiement » PvP. CLS est aujourd’hui opérationnel pour 18 devises, est détenu par 74 banques/institutions financières et plus de 9000 autres institutions qui opèrent en tant que participants indirect.

Qu’entendons nous par risque de règlement ou “Settlement Risk” dans le cadre des opérations de change ? (Cross Currency Settlement Risk ou Herstatt Risk, en référence à la banque Allemande Herstatt dont la faillite en 1974 a très bien illustré ce type de risque).

Voici comment est défini le risque de règlement dans les opérations de change selon le rapport Allsopp qui fait autorité en la matière : «  le risque que l’une des parties à une opération de change livre la devise qu’elle a vendue sans recevoir la devise qu’elle a achetée ». Ce risque est symétrique pour les deux parties participant a une opération de change. Cela est dû au fait que les deux schémas de règlement pour l’échange de deux devises entre deux banques s’exécutent de façon indépendante et dans une durée qui peut s’étendre sur plusieurs jours (souvent c’est un schéma d’échange basé sur du settlement banking). Le temps d’exposition représente le laps de temps pendant lequel l’une des parties a livré  sa part de la transaction alors que sa contrepartie ne l’a pas encore fait et que celle-ci finisse par faire un défaut de règlement.

Comment le système CLS permet-il d’éviter ce type de risque ?

Les institutions financières participant directement au système CLS possèdent un compte multidevises détenu par la CLS Bank comportant une position par devise. Le traitement des opérations liées à ce compte se font sur le principe « paiement contre paiement » : Une opération ne sera exécutée sur un compte que si chacune des contreparties possède sur son compte CLS une position suffisante dans la devise qu’elle doit livrer. Si cette condition est satisfaite l’opération est alors exécutée de façon immédiate, simultanée et irrévocable sur les comptes des deux contreparties.

Le solde net de chaque devise pour chaque participant fait l’objet d’un règlement en monnaie centrale. Si l’un des participants possède une position nette débitrice sur une devise dans les livres de la CLS Bank celui-ci devra régler la CLS Bank à hauteur de cette position en monnaie centrale. De même pour un participant ayant une position nette créditrice, ce sera alors à la CLS Bank de lui régler un montant égale à cette position.

Le règlement de ces postions débitrices et créditrices (Pay-ins/Pay-outs) se fait via des systèmes de règlement de type RTGS (Real Time Gross Settlement), ce type de système permet l’exécution de ces opérations en temps réel et de façon irrévocable en monnaie centrale.

Les contrôles de risque que CLS applique à ses participants :

Le solde global d’un compte multidevises doit être créditeur ou nul.
La position est débitrice pour une devise donnée ne peut dépasser un certain seuil (Short position limit ou SPL )
La somme des positions débitrices, toutes devises confondues sur un compte, ne doit pas dépasser un certain seuil (Aggregate short position limit ou ASPL)

Le risque dans les opérations de change est considéré comme un risque systémique sur l’économie mondiale comme cela a été démontré à moindre échelle par la faillite de la Bankhaus Herstatt en 1974. Le système CLS apporte donc une sécurité et une stabilité non négligeable sur le marché des changes qui ont très certainement pesées dans le maintien de l’activité de ce dernier durant la crise financière qui a fait suite, entre autres, a la faillite de Lehman Brothers en 2008 ; En outre, CLS vise à l’intégration de nouvelles devises et à l’augmentation continuelle des volumes traités, il est fort à parier que la place du système CLS dans le paysage des marchés financiers ne fera que croître dans les années à venir.

facebooktwittergoogle_plusmail

Optimiser son temps : le pomodoro

Christian

A la recherche d’une technique d’optimisation du temps, j’ai fait la découverte du pomodoro. Cette technique de travail existe depuis les années 80.

L’idée est de découper sa journée en périodes de 25 minutes entrecoupées par des pauses de 5min. Tous les 4 pomodori, on effectue une “grande pause” de 10 à 15 minutes.

Eliminer les interruptions

Pendant une période de 25 minutes, on se concentre sur une seule et même tâche que l’on refusera poliment et fermement d’interrompre :). La tâche choisie doit être finie à la fin des 25 minutes.

Si malgré tout, il faut s’interrompre avant la fin de la période, il faut essayer de finir son pomodoro.

De cette façon lorsqu’on reprends le travail, la tâche précédente est finie. La période suivante commence sur une feuille blanche.

A noter que la période d’activité de 25 min ne corresponds pas à un découpage que vous auriez fait dans votre outil de gestion de tâche.

Un pomodoro n’est pas équivalent à une tâche technique découpée en sprint planning. C’est un découpage personnel.

Au bout de 25 min, la petite pause

Au bout de 25 minutes, on effectue une petite pause de 5 minutes. Au risque de décevoir, cette interruption volontaire n’est en réalité pas tout à fait une pause.

Ce temps va vous permettre de traiter toutes les évènements qui aurait du/pu vous interrompre : lecture de mail, question d’un collègue etc … .

Durant ces quelques minutes où l’on ne travaille plus sur sa tâche principale, le cerveau “s’aère”. Ceci permet d’éviter l’effet tunnel qui apparaît lors de trop de grandes périodes de concentrations.

Au début du pomodoro suivant, on relit le code qu’on vient d’écrire, la spéc et on prends du recul.

Tous les 4 pomodori, la grande pause

4 pomodori représente 2H de travail et 20 minutes de temps de gestion des petites interruptions – ou petites pauses.

C’est le moment de la grande pause. On en profite pour aller se chercher un café, discuter de ce nouveau framework avec votre collègue … .

Celle ci est la vraie pause ;).

L’inversion de dépendance

Un effet “sympathique” du pomodoro est l’inversion de dépendance vis à vis de l’extérieur.

Vous traitez les évènements qui aurait du vous interrompre toutes les 25 minutes.

Ce sont maintenant les évènements qui vont attendre d’être traités à la fin de votre pomodoro.

Avec modération

Gardez bien en tête qu’il faut être souple et notamment un des principes Agile : Les individus et leurs interactions, plus que les processus et les outils.

Appliquer le pomodoro de manière rigide n’est pas une solution.

Dans le cas d’un évènement bloquant pour l’équipe, c’est l’équipe qui aura la priorité. Certes, on tente de terminer proprement le pomodoro dans un temps raisonnable si les conditions le permettent.

Un bug de production ne va pas attendre la fin de votre pomodoro ;).

Ressources

facebooktwittergoogle_plusmail

La sous qualité, une norme ?

Christian

Je me rends régulièrement au meetup Software Craft(wo)manship in Paris. Lors de la dernière séance une discussion concernant la qualité du code s’est engagée.

La sous qualité comme sous norme

Un constat des craftmans présents est que la qualité coûte cher. Ce constat vient de la vision court-termiste qu’a le client de son application.

Le temps de développement est perçu comme un poste de dépense. Il faut délivrer le plus vite possible. Il en résulte une pression accrue sur les équipes de développements qui n’ont plus le temps de structurer et développer un produit fini.

Le résultat est une application buggée. Le développement de fonctionnalité se transforme en TMA. Plus exactement, l’équipe répare.

La qualité coûte cher

Voici un des principaux préjugés qui explique la « normalisation » de la sous qualité.

Le client perçoit son logiciel comme une dépense, un fardeau. C’est pourtant un investissement qui lui permettra d’augmenter sa performance.

Sans faire de calculs profonds, une TMA de plusieurs mois (année ?) coûtera plus chère qu’une majoration 15 à 30% du temps développement initial avec TDD.

Trouver les arguments

Réduction du turn over

La qualité du code a un effet sur le moral des équipes. Une mauvaise qualité de code entraine une démotivation. La perspective des développeurs au réveil le matin s’apparente à réparer ce qui s’effondre pour pouvoir livrer les ruines.

Le développeur finit par partir, lassé. Il faut le remplacer – et mobiliser des ressources pour recruter.

N’oublions pas que la sous qualité engendre la sous qualité. Il devient de plus en plus difficile d’ajouter des fonctionnalités sans provoquer des régressions. La correction des régressions consume le temps prévu pour les évolutions. C’est un cercle vicieux.

Le logiciel en tant qu’investissement

Le monde est digitalisé en ces derniers jours de 2015. Il n’est par exemple plus possible pour une banque d’investissement d’avoir une panne de son système d’information. Il n’est pas envisageable pour un trader d’être incapable de conclure une transaction.

Le logiciel est, dans l’exemple des BFIs, au centre du business. Il permet de conclure le deal avant le rival. Les logiciels sont les outils sur lesquels reposent les marchés.

Au même titre qu’un couteau émoussé, un logiciel buggé, instable, avec un time to market trop important, ne permettra pas à son utilisateur de travailler correctement. Il perdra du temps.

Les bugs cassent le workflow de l’utilisateur. Il doit s’interrompre dans son travail. L’apparition de bug dénote l’instabilité qui réduit la confiance de son utilisateur dans son outil.

Le développement d’une fonctionnalité prends des mois – le fameux time to market – l’utilisateur exécute manuellement des traitements automatisables en attendant sa fonctionnalité.

En un mot l’utilisateur perds du temps. Ce qui, en finance, peut prendre des proportions vertigineuses…

Conclusion

L’amélioration de la qualité de code par l’utilisation de méthodologies telles que TDD ou BDD permet d’améliorer la fiabilité des livrables.

Elle représente un coût réduit par rapport à une TMA de plusieurs mois. D’autre part, une bonne qualité permet de réduire le turn over. Coté utilisateur, la qualité donne confiance à l’utilisateur dans votre équipe.

Enfin un code de qualité garantit la possibilité pour une application d’évoluer sereinement.

Conseil lectures

facebooktwittergoogle_plusmail

Meetup Paris Software Craft(wo)manship le 15/12/2015

Christian

Les inscriptions pour le meetup Software Craft(wo)manship le 15/12/2015 sont ouvertes.

L’idée est de se rassembler autour de sujets liés à l’industrie logicielle. Ces sujets peuvent être techniques comme fonctionnels ou orientés management.

La soirée se déroule en deux phases. Dans un premier temps, des lightning talks de quelques minutes, suivis de mini workshop autour des thématiques proposées par les participants.

Apprendre et échanger sont les maîtres mots de la soirée.

Il n’y a plus beaucoup de places disponibles !

La présentation du Meetup par lui même :

La communauté Software Craftsmanship Paris réunit les développeu(r|se)s, sans sexisme, élitisme, ni langage ou techno obligatoire.

Si vous êtes intéressé(e)s par le Test-Driven Development, Agile Testing, les challenges du code legacy, BDD, DDD, l’attitude clean coder, les problématiques de design, rejoignez-nous immédiatement pour être informés de tous nos événements !

En tant qu’aspirants artisans du logiciel, nous relevons le niveau du dévelopement professionnel de logiciels par la pratique et en aidant les autres à acquérir le savoir-faire.

Grâce à ce travail, nous avons appris à apprécier :

  • Pas seulement des logiciels opérationnels, mais aussi des logiciels bien conçus.
  • Pas seulement l’adaptation aux changements, mais aussi l’ajout constant de la valeur.
  • Pas seulement les individus et leurs interactions, mais aussi une communauté de professionnels.
  • Pas seulement la collaboration avec les clients, mais aussi des partenariats productifs.

C’est-à-dire qu’en recherchant les éléments de gauche, nous avons trouvé que les éléments de droite sont indispensables.

Le meetup Sofware Crafts(wo)manship in Paris

facebooktwittergoogle_plusmail