Hybridizer supports generics and virtual functions. These concepts allow writing flexible code with type parameters, defering actual behavior resolution to type instanciation by client code. These are fondamental features of modern languages, easing encapsulation, code factorization and concepts expression.

However in C#, type parameters are resolved at runtime, which comes with a significant performance penalty. Hybridizer maps them to C++ templates, which are resolved at compile time. As such, templates allow inlining and interprocedural optimization as in plain C code. Performance penalty is therefore inexisting.

As an example, we will demonstrate usage of generics on a fun mathematical example : the resolution of heat equation with random walks.

Mathematic background

Given a connected bounded 2D domain Ω in ℝ2, its border ∂Ω and a function 𝑓∈:L2(∂Ω), we search 𝑢 such as:

Δ𝑢=0 on Ω

𝑢=𝑓 on ∂Ω

Classic ways to numerically solve this problem involve finite elements or similar discretization methods which come with different regularity constraits on ∂Ω.

It happens we can solve it using montecarlo methods by launching brownian motions. For each point (𝑥,𝑦) in Ω we launch 𝑁 random walks. For each random walk, we wait until it reaches ∂Ω and sample the temperature at exit point. We then sum all those exit temperatures and divide by 𝑁 to get the numerical solution :

This method is quite slow (compared to finite elements or similar). But it has some advantages:

• It can easily be distributed among many threads (all points are independants)
• It’s possible to compute the solution at a specific location
• Ω has almost no regularity constraint (external cone)
• Absolutely no memory footprint (except for the solution)
• It works similarly in higher dimensions

Full explanations can be found on this old research report (in french).

Code

We structured our code as would be a generic mathematical solver. The main class is MonteCarloHeatSolver, which takes a I2DProblem to solve it.
This code is generic and solves a problem described by an interface:

 public class MonteCarloHeatSolver
 {
  I2DProblem _problem;
  
 public MonteCarloHeatSolver(I2DProblem problem)
 {
  _problem = problem;
 }
  
 [EntryPoint]
 public void Solve()
 {
 int stopX = _problem.MaxX();
 int stopY = _problem.MaxY();
 for (int j = 1 + threadIdx.y + blockIdx.y * blockDim.y; j < stopY; j += blockDim.y * gridDim.y) {
 for (int i = 1 + threadIdx.x + blockIdx.x * blockDim.x; i < stopX; i += blockDim.x * gridDim.x) {
  float2 position;
  position.x = i;
  position.y = j;
  _problem.Solve(position);
 }
 }
 }
 } 

where actual resolution (geometry related) is deferred to a I2DProblem. The call to Solve (virtual) won’t be matched to templates. But the Hybridizer will handle this and dispatch this call correctly at runtime. This will cost a vtable lookup, but only once per thread. Performance critical code is in the random walk and the boundary conditions, which are generic parameters of the 2D problem.

An example of C# code instanciation can be:

 var problem = new SquareProblem<SimpleWalker, SimpleBoundaryCondition>(N, iterCount);
 var solver = new MonteCarloHeatSolver(problem);
 solver.Solve(); 

We then have two interfaces describing random walks and boundary conditions :

 [HybridTemplateConcept]
 public interface IRandomWalker
 {
 [Kernel]
 void Init();
 [Kernel]
 void Walk(float2 f, out float2 t);
 }
 [HybridTemplateConcept]
 public interface IBoundaryCondition
 {
 [Kernel]
 float Temperature(float x, float y);
 } 

These interfaces are decorated with [HybridTemplateConcept] which tells the Hybridizer that these types will be used as type parameters. They can be extended by actual classes such as:

 public struct SimpleBoundaryCondition : IBoundaryCondition
 {
 [Kernel]
 public float Temperature(float x, float y)
 {
 if ((x >= 1.0F && y >= 0.5F) || (x <= 0.0F && y <= 0.5F))
 return 1.0F;
 return 0.0F;
 }
 } 

Generic types using these interfaces have to tell the hybridizer how they want it to generate template code from generics. This is again done by using attributes:

For example:

 [HybridRegisterTemplate(Specialize = typeof(SquareProblem<SimpleWalker, SimpleBoundaryCondition>))]
 public class SquareProblem<TRandomWalker, TBoundaryCondition>: I2DProblem 
  where TRandomWalker : struct, IRandomWalker 
  where TBoundaryCondition: struct, IBoundaryCondition
 {
  // other interface methods implementations
  // ...
  
 [Kernel]
 public void Solve(float2 position)
 {
  TRandomWalker walker = default(TRandomWalker);
  TBoundaryCondition boundaryCondition = default(TBoundaryCondition);
  walker.Init(); // generic parameter method call -- will be inlined
 float temperature = 0.0F;
 float size = (float)_N;
 for (int iter = 0; iter < _iter; ++iter)
 {
  float2 f = position;
  
 while (true)
 {
  float2 t;
  walker.Walk(f, out t); // generic parameter method call -- will be inlined
  
  // when on border, break
 if(t.x <= 0.0F || t.y >= size || t.x >= size || t.y <= 0.0F)
 {
  // generic parameter method call -- will be inlined
  temperature += boundaryCondition.Temperature((float)t.x * _h, (float)t.y * _h);
 break;
 }
  
  // otherwise continue walk
  f = t;
 }
 }
  
  _inner[((int)(position.y - 1)) * (_N - 1) + (int)(position.x - 1)] = temperature * _invIter;
 }
  
 } 

 [HybridRegisterTemplate(Specialize = typeof(TetrisProblem<SimpleWalker, TetrisBoundaryCondition>))]
 public class TetrisProblem<TRandomWalker, TBoundaryCondition> : I2DProblem
  where TRandomWalker : struct, IRandomWalker
  where TBoundaryCondition : struct, IBoundaryCondition
 {
  // actual interface implementation
 } 

Results

Dispatchant calls

Virtual functions trigger a callvirt in the MSIL.

IL_005e: callvirt instance void MonteCarloHeatEquation.I2DProblem::Solve

Profiling the generated code with nvvp shows us that a vtable is generated by the Hybridizer (ensuring the right method is called):

Generics and templates

On the other hand, IRandomWalker and IBoundaryCondition type parameters are mapped to templates. Their methods are therefore inlined, as shown in this nvvp profiling:

By the way: the images above show that your C# code is linked to the sass in the profiler. See our post about debugging and profiling

Conclusion

With few restrictions, you can safely use generics type parameters and dispatchant calls in your C# code. Hybridizer will map that to the correct concept (vtable or template) as your required for.
Dispatchant calls give you full flexibility of an inheritance hierarchy, but come at a performance cost. On the other hand, generics deliver full performance (inlined calls), as long as the right metadata has been provided.

The post Generics and virtual functions first appeared on In Fine - Le Blog.

We describe here the implementation of Mandelbrot fractal image generation using Hybridizer. The language of choice is C#, and implementation is done using 32-bits precision arithmetic.

Mandelbrot set is the set of values c for which the sequence:

remains bounded in the complex plane.
It happens an equivalent definition is:

That means that while calculating 𝑧𝑛 values exceeds 2 at any iteration, the point c is not in the set.

C# implementation

In other words, this can be simulated via this code:

public static int IterCount(float cx, float cy)
{
    int result = 0;
    float x = 0.0f;
    float y = 0.0f;
    float xx = 0.0f, yy = 0.0f;
    while (xx + yy <= 4.0f && result < maxiter) // are we out of control disk?
    {
        xx = x * x;
        yy = y * y;
        float xtmp = xx - yy + cx;
        y = 2.0f * x * y + cy; // computes z^2 + c
        x = xtmp;
        result++;
    }

    return result;
}

which has to be run for every point (cx, cy) in the complex plane.
To produce an output image, we therefore compute IterCount for every pixel in the square [−2,2]×[−2,2], discretized as a 𝑁×𝑁 square grid:

public static void Run(int[] light)
{
    for (int i = 0; i < N; i += 1)
    {
        for (int j = 0; j < N; j += 1)
        {
            float x = fromX + i * h;
            float y = fromY + j * h;
            light[i* N + j] = IterCount(x, y);
        }
    }
}

where N, h, fromX and fromY are application parameters.
We here compute a 2048×2048 image using C# on a core i7-4770S @ 3.10GHz.
This unoptimized versions runs in 420 milliseconds, yielding

Its crystal clear that this code is embarrassingly parallel, since all pixels are independant from each other.

A first trivial optimization would therefore to make the first loop parallel:

public static void Run(int[] light)
{
    Parallel.For(0, N, (i) => {
        for (int j = 0; j < N; j += 1)
        {
            float x = fromX + i * h;
            float y = fromY + j * h;
            light[i * N + j] = IterCount(x, y);
        }
    });
}

This second version runs in 67 milliseconds, giving:

Run on the GPU

In order to run that on a GPU, we just need to decorate the Run method with EntryPointAttribute:

[EntryPoint("run")]
public static void Run(int[] light)
{
    Parallel.For(0, N, (i) => {
        for (int j = 0; j < N; j += 1)
        {
            float x = fromX + i * h;
            float y = fromY + j * h;
            light[i * N + j] = IterCount(x, y);
        }
    });
}

and some boilerplate code to invoke the generated method:

HybRunner runner = HybRunner.Cuda("Mandelbrot_CUDA.dll").SetDistrib(N, 128);
wrapper = runner.Wrap(new Program());
wrapper.Run(light_cuda);

This modified code runs on the GPU (a 1080 Ti) in 10.6 milliseconds (32 when counting the memory copies), giving:

Further optimization

Launching a block per image line is highly suboptimal, due to the unevenly distribute nature of the computations. For example, threads at the square’s border will immediately converge, while those on the set will take the longest runtime.
This can be seen by profiling the above code using Nsight:

As we can see, half of multiprocessors are idle.

We can instead distribute the work more evenly by using a 2D grid of relatively small blocks.

Fortunately, Hybridizer supports CUDA-like parallelism, so we can modify our entrypoint this way:

[EntryPoint("run")]
public static void Run(int[] light)
{
    for (int i = threadIdx.y + blockDim.y * blockIdx.y; i < N; i += blockDim.x * gridDim.x)
    {
        for (int j = threadIdx.x + blockDim.x * blockIdx.x; j < N; j += blockDim.y * gridDim.y)
        {
            float x = fromX + i * h;
            float y = fromY + j * h;
            light[i * N + j] = IterCount(x, y);
        }
    }
}

and run it with a 2D grid:

HybRunner runner = HybRunner.Cuda("Mandelbrot_CUDA.dll").SetDistrib(32, 32, 16, 16, 1, 0);

The modified code runs now in 920 microseconds on the GPU, meaning:

If we profile the newly generated kernel, we get:

main stall reason being “Other” with 69% followed by instruction fetch for only 5% of not eligible warps.
It’s reasonable to not try further optimization.

Conclusion

In this post we presented a basic usage of hybridizer, from unoptimal c# to highly efficient generated cuda code. We started by optimize our c# code and the migrated it seamlessly to CUDA.
We then optimized our c# code for CUDA GPUs, until we reached a close to peak performance level.

The post Mandelbrot with Hybridizer first appeared on In Fine - Le Blog.

Vue d’ensemble (définitions et normes)

Les tests informatiques sont destinés à évaluer si un système informatique et ses composants satisfont les exigences métier ou pas. Cette activité résulte des différences qu’il pourrait y avoir entre le résultat attendu et le résultat réellement obtenu.

Les tests peuvent couvrir l’analyse et la vérification des exigences métier, la révision de la conception ainsi que la vérification et la validation du code d’un développeur. Les tests peuvent commencer dès la phase de recueil du besoin et dure jusqu’au déploiement de l’application livrée. Si le démarrage des tests peut commencer assez tôt dans le cycle de développement en imaginant les cas de tests, y mettre fin serait un casse-tête face à un testeur perfectionniste. L’arrêt des tests arrive en général quand les dates jalons sont atteintes, quand les cas de tests couvrent un certain périmètre fonctionnel, quand le taux d’anomalies est réduit à un minimum ou tout simplement par une décision de gestion. Il y a beaucoup de termes en relation avec les tests. Passons les en revue.

L’assurance qualité est une activité visant l’implémentation de processus, de procédures et de standards dans le contexte du développement d’applications informatiques. Elle a pour but la prévention d’anomalies et fait partie du cycle de vie des tests d’applications informatiques.

Le contrôle qualité est une activité destinée à vérifier que le logiciel développé respecte les exigences métier. Il met en application les processus définit par l’assurance qualité. C’est une activité corrective et se focalise sue un logiciel particulier. Il peut être considéré que le contrôle qualité est un sous-ensemble de l’assurance qualité.

Les tests informatiques sont l’activité d’identification des bugs, anomalies et défauts d’un logiciel. Ils sont un sous-ensemble de l’assurance qualité.

L’audit est un examen  des processus  de testing exitants. Il est mené par un organisme externe aux développeurs et aux testeurs et délivre un certificat ou un accréditation.  C’est une comparaison  des processus documentés et des processus vraiment déroulés.  L’audit peut se décliner en audit de conformité, audit légal, audit interne, audit du système et autres.

Les inspections sont des examens des exigences métiers, de la conception et du code. Elles sont effectués par une tierce personne et vise au respect des processus documentés. A différence de l’audit, il n’y a pas de certifications.

Le testing est l’identification de bogue, d’anomalies et de défauts. C’est une activité qui vise le repérage mais pas la correction. Cette dernière est réalisée par d’autres équipes

Le débogage est l’identification, la qualification et la correction des anomalies.

La norme ISO/IEC 9126 définit un langage de modélisation de la qualité des logiciels. Le langage de description utilise des termes tels que “facteurs qualité” , “caractéristiques, “sous-caractéristiques ,”métriques” pour classer de façon arborescente et structurée, sur la base de définitions standardisées, un vocable de plusieurs dizaines de propriétés en “ité” (portabilité, maintenabilité, fiabilité, etc.)

• Capacité fonctionnelle : Est-ce que le logiciel répond aux besoins fonctionnels exprimés ?
• Fiabilité : Est-ce que le logiciel maintient son niveau de service dans des conditions précises et pendant une période déterminée ?
• Facilité d’utilisation : Est-ce que le logiciel requiert peu d’effort à l’utilisation ?
• Rendement / Efficacité : Est-ce que le logiciel requiert un dimensionnement rentable et proportionné de la plate-forme d’hébergement en regard des autres exigences ?
• Maintenabilité : Est-ce que le logiciel requiert peu d’effort à son évolution par rapport aux nouveaux besoins ?
• Portabilité : Est-ce que le logiciel peut être transféré d’une plate-forme ou d’un environnement à un autre ?

ISO/IEC 9241-11 aborde l’usage d’un produit par des utilisateurs dans un contexte donnée afin d’atteindre des objectifs de safistaction et d’efficacité.

ISO/IEC 25000 remplace ISO-9126 and ISO-14598 et définit des guides d’utilisation SQUARE (Software product Quality Requirements and Evaluation)

IEEE est l’acronyme de “institute of Electrical and Electronics Engineers”. Il définit aussi des normes spécifiques à des contextes du testing comme les tests unitaires, les plans des tests et de recette, la classification des anomalies etc.

Types de tests

Les tests peuvent être catégorisés suivant la manière comme ils sont réalisés. Ils sont soit manuels soit automatisés

Lors des tests manuels, le testeur adopte le point de vue de l’utilisateur final et procède à la recherche d’un comportement non-conforme.  Il y a plusieurs niveaux de profondeur de testing. Ceux-ci seront expliqués par la suite.

Les tests automatisés sont effectués quand le testeur écrit un script d’automatisation et les tests eux-mêmes sont exécutés par un logiciel dédié à l’exécution des tests. L’automatisation permet de dérouler plusieurs fois le même test ce qui est propice aux tests de non régression.  Les domaines qui se prêtent à l’automatisation sont des transactions comme le login ou le remplissage de formulaires ou l’accès simultané peut générer des pics d’utilisation. Il est recommandé d’automatiser dans de très grands projets, quand la même fonctionnalité est testée fréquemment, quand les exigences sont stables, dans des situations visant des  critères de performance et de robustesse d’accès.

Les étapes de l’automatisation sont les suivantes :

• Identification des domaines d’automatisation
• Sélection de l’outil d’automatisation
• Ecriture des scripts et des enchainements
• Exécution des tests
• Génération des rapports
• Analyse des résultats

Parmi les logiciels d’automatisation on trouve  entre autres HP Quick Test Professional, Selenium, IBM Rational Functional Tester, SilkTest, TestComplete, Testing Anywhere, WinRunner, LaodRunner, Visual Studio Test Professional et WATIR.

Méthodes de testing

Dans la méthode de boite noire, le testeur n’a pas de connaissances sur le code et l’architecture. Le testeur utilise l’IHM et examine les résultats obtenues. Les avantages sont l’’adaptation à des périmètres très grands, la bonne séparation de la vision de l’utilisateur final et du développeur et l’absence de connaissances techniques poussées.  Le risque de cette méthode est la couverture inappropriée de certaines parties du logiciel.

Dans la méthode de la boite blanche, une investigation détaillée de la structure et de la logique du code est conduite.  Une  connaissance technique du langage de programmation et des modules des logiciels testés est requise.  En boite blanche, le code peut être optimisé et il est plus probable de couvrir la totalité des cas. D’un autre côté, cette métode est plus couteuse dans le sens où  il faut maintenir des outils spécialisés comme les analyseurs de code et de débogage. Aussi les ressources sont plus chères car il faut qu’elles aient la connaissance des techniques en lien avec le logiciel testé.

Dans la méthode de boite grise, le testeur a accès aux documents de conception et au modèle de base de données. Ceci lui permet de préparer les données de tests et les scénarios de tests.

Catégories de tests

Il y a deux niveaux de tests, chacun divisé en sous-catégories : Les tests fonctionnels et les tests non fonctionnels

Les tests fonctionnels  se basent sur les spécifications fonctionnelles.  Le logiciel est testé dans un environnement afin de vérifier sa conformité aux exigences (requirements). Les étapes qui les composent sont les suivantes ;

• Détermination de la fonctionnalité testée
• Ecriture des scénarios de test et des cas de test
• Création des données de tests
• Détermination de la sortie
• Comparaison des résultats obtenus et des résultats attendus.

Les tests non-fonctionnels sont basés sur des critères applicatifs détaillés dans le dossier d’architecture système, les exigences non-fonctionnelles. Ils sont donc menés par des experts techniques

Les tests de performance cherchent à identifier des problèmes de performance et des goulots d’étranglement. Les différentes causes peuvent être la lenteur du réseau, les traitements des bases de données,  la répartition de charge (load balancing).   Parmi les tests de performance, les tests de charge simulent des connexions et des manipulations de données avec des scripts d’automatisation. Ainsi l’application dévoile son comportement aux heures de pointe de l’utilisation. Les tests de stress poussent le système à ses limites et dans des situations risqué (perte de connexion au réseau ou à une base de données ou surcharge des processus machine)

Les tests de convivialité (usability) permettent d’évaluer la satisfaction de l’utilisateur quand celui-ci se fixe un objectif opérationnel et  quand cet objectif est atteint de manière efficace. Ils mesurent les interactions de l’utilisateur dans l’atteinte d’un but précis.

Les tests de sécurité ont pour vocation l’identification de failles et de vulnérabilités en termes de sécurité.  Ces tests garantissent la confidentialité, l’intégrité des données, la protection contre des attaques malveillantes, le respect de réglementations spécifiques à la banque etc…

Les tests de portabilité assurent que l’application peut être installée et exécutée dans un autre système.

A part ces catégories de tests, l’IEEE-Std 830 – 1993 liste 13 exigences non-fonctionnelles :

• performance
• interface
• opérationnel
• sur les ressources
• vérification
• validation / recette
• documentation
• sécurité
• portabilité
• qualité
• fiabilité
• maintenabilité
• sauvegarde

Documentation relative aux tests

Le plan de tests résume la stratégie de tests visée pour l’application. Il inclut les sections suivantes :

• hypothèses
• liste des cas de test
• liste des fonctionnalités
• liste de livrables
• liste des ressources humaines et matérielles
• risques
• planning et jalon

Les scénarios de test sont des regroupements de cas de tests. Le cas de test est un ensemble de pas à suivre. Elle est représentative d’un situation opérationnelle. Voici l’exemple du formalisme de représentation.

A l’issue des tests, des anomalies seront relevées dans des fiches descriptives.  Il sera important donc de dressée la matrice de traçabilité.  Ce document fait le lien entre les exigences, les tests prévus, les tests exécutés et les anomalies déclarées.

L’outil « Quality Center » permet d’informatiser e processus. Le module « requirements » permet de saisir les exigences. Le module « Test Plan » permet de décrire  les cas de tests et les organisent sous forme arborescente de sorte à produire des scénarios de tests. Le module « Test Lab » représente une exécution donnée pour un scénario de tests.   Un scénario de tests peut être exécuté plusieurs fois . L’exécution peut avoir lieu manuellement ou automatiquement. De ce fait, Quality Center permet de générer des scripts d’automatisation.  Après une exécution,  les anomalies déclarées peuvent être liés aux cas de tests. Finalement, Quality Center offre la possibilité de générer des rapport sur l’état d’avancement des tests.

 Références

The post Tests informatiques first appeared on In Fine - Le Blog.

Le présent article se concentre sur l’histoire des cartes bancaires, les bases des transactions par carte et les retraits dans les distributeurs automatiques de billets,  la norme EVM des cartes à puces  et finalement  la norme  SEPA des cartes (SCS, SEPA card scheme).

Un peu d’histoire

En France, le groupement des cartes bancaires est le groupement d’intérêt économique qui gère le réseau interbancaire français des distributeurs de billets et de terminaux électroniques de paiement. Ce réseau est indépendant des réseaux Visa et MasterCard et est interconnecté à ceux-ci.  Le site www.cartes-bancaires.com résume l’histoire des avancées technologiques des cinquante dernières années. Il est surprenant d’apercevoir les changements encourus. Ce qui était une innovation pendant le vingtième siècle, du point de vue du vingt-et-unième  n’est qu’un objet de la vie courante comme le sont la voiture, la télévision ou internet.

Les paiements sur TPE, les retraits sur DAB et les acteurs

L’expérience de retrait d’argent dans un distributeur automatique de billet et le règlement d’une somme d’argent sur un terminal de paiement électronique chez un commerçant sont des actions courantes. Le titulaire de la carte (cardholder) utilise le TPE d’un commerçant (merchant)  ou le DAB d’une banque quelconque. Dans les deux cas, le titulaire de la carte initie la demande d’autorisation qui transite par le  réseau de carte (card scheme).  La demande est transmise de l’acquéreur (acquirer) vers  l’émetteur de la carte (issuer). Une fois que l’autorisation est donnée par l’émetteur, celle-ci retourne sur le terminal (DAB,TPE) comme dans la figure ci-après.

Figure 1, L’opération de paiement (source cartes bancaires)

Dans un deuxième temps, les règlements ont lieu. Régulièrement, les transactions bancaires sont remises à la  banque du commerçant, l’acquéreur,  et celui-ci crédite le compte du commerçant. Les transactions des commerçants, clients de l’acquéreur, sont transmises à la chambre de compensation de détail.  En France, elle s’appelle CORE (COmpensation REtail).  Finalement, les sommes sont débitées des comptes des titulaires de la carte.

Figure 2, le règlement et la compensation (source cartes bancaires)

Le tiulaire de la carte (cardholder) est le nom de la personne qui est inscrit sur la carte. Le porteur et le titulaire peuvent être différents. C’est le cas des cartes professionnelles.

Le commerçant (merchant) signe un contrat avec l’acquéreur où sont stipulées les conditions d’utilisation des terminaux et les commissions prélevées sur chaque transaction ou type de carte.

L’acquéreur  (card acquirer) est l’entité qui gère le compte du commerçant. Il transmet les informations des transactions aux émetteurs de cartes pour traitement ultérieur et garantit que le compte du commerçant est crédité.

L’émetteur de cartes (card  issuer) est l’institution financière qui met à disposition la carte au titulaire de la carte. Il gère le compte du titulaire et peut lui octroyer une ligne de crédit. Il autorise les transactions sur les TPE ou DAB et garantit que le paiement sera régler auprès de l’acquéreur en fonction des arrangements commerciaux établis avec le réseau de cartes.

Entre l’émetteur et l’acquéreur se trouve le réseau de d’acceptation de paiements (card scheme).  Le réseau de cartes fait référence à l’infrastructure interbancaire d’acceptation de paiement par carte. En France ce réseau est indépendant  des réseaux internationaux tels que Visa ou Mastercard. Il s’appelle e-rsb.   Le terme « card scheme » fait  aussi référence au  contrat commercial qui permet à une marque donnée  de carte de paiements  de fonctionner dans un cadre légal, organisationnel et opérationnel.  Un réseau de carte assure les standards techniques des TPE, des DAB et de  l’infrastructure technique d’échanges. Il établit aussi  les termes légaux en cas de fraude et de litige.

Il y a deux configurations possibles pour les réseaux de paiements.

Figure 3, système quatre coins (source wikipedia)

Le système quatre coins sépare l’acquéreur de l’émetteur. C’est un réseau ouvert ou une banque ou une institution financière peut devenir membre  à condition de respecter le cadre technique du réseau. Visa et Mastercard en sont des exemples.

Figure 4, système 3 coins (source wikipedia)

Le système de trois coins est un réseau ou l’acquéreur et l’émetteur sont le même. Il n’y aura donc pas besoin de passer par une chambre de compensation ni de régler des commissions entre acquéreur et émetteur. C’est un réseau fermé.  Diners et American Express en sont des exemples.

Figure 5, Les commissions (source : payment systems,  ECB)

Chaque fois qu’un paiement par carte a lieu, la commission d’interchange est prélevée.  Elle couvre les coûts  de traitement, les coûts des garantis en cas de fraude et la période de crédit accordée au titulaire de la carte.  Elle est calculée suivant un pourcentage de la transaction, suivant un coût fixe par opération ou une combinaison des deux. La commission d’interchange est payée par l’acquéreur à l’émetteur.  De leur côté, le commerçant paie une commission à l’acquéreur et le titulaire de la carte paie une commission à l’émetteur. Suivant le type de carte, le titulaire aura droit à certains bénéfices comme le service de rapatriement en cas d’accident et autres. Dans le cas d’un retrait d’espèces, les mêmes types de commissions sont prélevées sauf pour le sens de la commission d’interchange. Celle-ci  est payée par l’émetteur à l’acquéreur principalement pour la maintenance du distributeur de billets. On peut se douter que ces commissions peuvent être  un débat houleux entre les commerçants et les acquéreurs ou entre les acquéreurs, les émetteurs et les réseaux d’acceptation de paiement par carte.  Le réseau d’acceptation de cartes peut forcer les commerçants à n’utiliser qu’une marque de carte. Les grands groupes commerciaux peuvent négocier des tarifs à leur avantage.  Enfin, le gouvernement peut intervenir dans l’adoption d’un code de conduite et de transparence comme ç’a pu être le cas au Canada  (cf : http://paymentsystemreview.ca)

Les specifications  EMV

EMV est l’acronyme de “Europay, MasterCard et Visa”. C’est un standard d’interopérabilité entre les cartes à puces (smartcard, IC card, integrated chip card) les TPE (terminaux de paiements électroniques, POS, point of sale) et les DAB (distributeurs  automatiques de billets, ATM, automated teller machine) destiné à identifier les transactions  des cartes de débit et de crédit par contact direct ou sans contact entre la carte et les terminaux.

EMVco est l’organisme chargé du maintien des spécifications et regroupe des réseaux de cartes américains, japonais et chinois.

Les avantages de la norme EVM sont:

• l’interopérabilité
• la gestion de plusieurs applications sur une même carte (carte de crédit, carte de débit, porte-monnaie électronique,…)
• l’autorisation en ligne et hors-ligne
• ‘l’augmentation des protocoles de sécurité etd’ identification avec le PIN (personal identity code)

La normes est composée de quatre volumes. Le premier est consacré aux caractéristiques de la carte à puce. Le deuxième aborde la sécurité, les protocoles de cryptage, les méthodes d’authentification et ses messages. Le troisième volume s’enfonce dans les dédales de la programmation de la carte. le quatrième volume détails les exigences des terminaux et des IHM.

Voici un aperçu des volumes 2 et 3. Les étapes du traitement d’une transaction se divisent comme il suit.

• « Selection de l’application » (Application selection) récupére le code d’identification de l’application d’une institution financière. Une banque peut avoir plusieurs codes correspondant à ses produits
• « Initiation du traitement de l’application » (Initiate application processing) . C’est l’exécution de PDOL (processing options data objects list,  le TEP-DAB envoie des données à la carte) de AIP (application interchange profile, la carte envoie des programmes que le TEP-DAB  devra exécuter) et de AFL (application file locator,  envoi d’une liste de pointeurs sur des fichiers de la carte)
• « Lecture des données des applications » (Read application data). Le TEP-DAB lit les fichiers fournis par AFL
• « Traitement des contraintes »( Processing restrictions) établit le cadre d’utilisation de la carte dans des limites prédéterminée (période d’utilisation, territoire géographique etc). Si les restrictions ne sont pas respectées, l’utilisation de la carte peut être refusée.
• « Authetitfication hors ligne » (Offline data authentication) est la validation de la carte moyennant un protocole de sécurité de clef publique et de clef privée (clef RAS). SDA (Static data authentication, authetification de données statiques) vérifie que la carte a été fabriquée par une banque émettrice (clef RSA de l’émetteur). Comme SDA peut être contourné par le clonage des cartes, DDA (Dynamic data authentication)  renforce la sécurité. Le protocole est basé sur la clef RSA de l’émetteur, la clef RSA de la carte elle-même et des données aléatoires et dépendantes de la transaction. CDA  (Combined DDA/generate application cryptogram ) est une authentification combinant DDA et SDA.
• « Vérification du titulaire de la carte » (Cardholder verification method) est la saisie du code PIN. Dans certains pays le PIN n’est pas implémenté et une signature sera requise.
• « La gestion du risque »( Terminal risk management ) est le choix entre la transaction hors ligne et en ligne en fonction du montant payé, une vérification aléatoire…
• « Analyse du terminal » (Terminal action analysis) est l’étape qui  en fonction des résultats des étapes ” traitement des contraintes”, “authentification  hors ligne”, « vérification du titulaire »,  et la  « gestion des risques » aboutit sur 3 résultats possibles : autorisation de la transaction hors ligne, refus de la transaction hors ligne ou autorisation de la transaction en ligne.
• « Première analyse de la carte »  est l’étape ou la carte répond avec 3 cryptogrammes: TC (Transaction certificate) autorisation hors ligne, ARQC (Authorization Request Cryptogram) autorosation en ligne, AAC (Application Authentication Cryptogram) refus du hors ligne
• Dans « Autorisation de la transaction en ligne »,  le terminal construit une demande de transaction en ligne pour être envoyée au terminal de l’émetteur.   Cette étape est obligatoire pour les DAB.
• « Seconde analyse de la carte » (Second card action analysis) est une étape ou le terminal envoie des données sur la carte.
• Le « traitement du script de l’émetteur » (Issuer script processing) est l’exécution d’un programme pour mettre à jour la carte. Elle peut être bloquée ou mise à jour avec des nouvelles données en provenance de l’émetteur.

La norme de cartes SEPA (SCS , SEPA card scheme)

Le conseil européen sur les paiements (european payment council)  maintient la norme SCS. La migration vers CSC a eu lieu en 2010 et la norme continue d’être mise à jour par exemple sur les paiements par mobile et paiements sans contact.

D’après la source http://sepafrance-temp.fr, Conformément au cadre d’interopérabilité SEPA, les paiements par carte doivent respecter les principes suivants :

• Les porteurs peuvent réaliser des paiements dans l’ensemble de l’espace SEPA avec leur carte, chez les commerçants qui l’acceptent.
• Les commerçants peuvent accepter dans les mêmes conditions les cartes sans distinction liée à leur pays d ‘ émission.  Ils conservent le choix des systèmes de cartes qu’ils acceptent.
• Les paiements par cartes utilisent la technologie EMV et sont le plus souvent authentifiés par un code PIN.
• Le paiement est garanti dans les conditions prévues par le réseau de cartes.

La norme CSC comporte six volumes.

• Le premier volume est un introduction qui souligne l’importance  de l’harmonisation des exigence du cadre SEPA pour les cartes. Ce volume explique le composition du groupe chargé de la maintenance et de la mise à jour de la norme et une liste exhaustive des termes et définitions et acronymes utilisés dans les autres volumes
• Le deuxième volume balaye les exigences (requirements) , les règles de gestion et les cas d’utilisation des transactions effectuées par carte sans perdre de vue les spécifications EMV sur laquelle la norme est basée. Les exigences couvrent l’utilisation de la carte, des DAB, des services pouvant être associés à la carte
• Le troisième volume est la description des données définies avec le standard XML 20022 et les formats d’échanges garantissant l’interopérabilité. Ce volume est accompagné d’une feuille Excel facilitant la conception architecturale  et l’harmonisation des messages d’autorisation et de compensation. Ceci peut être comparé à la définition des classes en langage objet.
• Le quatrième volume se spécialise sur le sujet de la sécurité des cartes et se réfère aux standards internationaux de la sécurité des cartes et s’adresse aux développeurs et experts en sécurité.
• Le cinquième volume aborde les procédures de vérification de la conformité aux normes SEPA des cartes, TPE et DAB.
• Le sixième volume est un guide d’implémentation. Il indique le calendrier de migration , des choix techniques de la norme EMV ( la liste des étapes décrites dans le chapitres EMV de cette article) et des cas d’utilisation  ou plutôt des contextes de paiements avec les parties obligatoires et optionnelles.

Conclusion

La norme CSC basée sur le standard EMV est la pierre angulaire des paiements sur terminaux auprès des commerçants et distributeurs de billets.  Mais ces modes de paiements ne seraient pas désuets? Le conseil européen sur les paiements a déjà commencé les discussions sur les normes des paiements sans contact et des paiements par mobile. Ces deux modes de paiement utilisent l’identification par radio-fréquence (RDFI, radio frequency identification). Soit la puce électronique de la carte est équipée de cette technologie, soit elle est intégrée à une puce insérée dans le téléphone portable. Il ne reste plus qu’à expérimenter ces nouveaux modes de paiement. Et si on manque d’imagination, il y des mises en scène sur le net:

Références

–>

The post Les paiements par carte first appeared on In Fine - Le Blog.

Bâle est une ville en Suisse  où se concentrent beaucoup d’horlogers. Elle abrite aussi le musée Tinguely, un artiste connu grâce à ses sculptures animées. La banque des règlements internationaux (BRI ou International Settlement Bank, ISB), la banque centrale de toutes les banques centrales,  y siège aussi.  Celle-ci héberge le comité de Bâle sur le contrôle bancaire (Basel Committee on Banking Supervision, BCBS) .  Ce club des gouverneurs des banques centrales  se réunit quatre fois par an et mène des discussions autour du contrôle, de la surveillance et  de la règlementation des banques. Cherchons de comprendre le contexte économique conduisant aux trois différents accords de Bâle et comment la vie des  banques se synchronise à l’heure de l’application des  normes prudentielles émanant du comité de Bâle.

Accords de Bâle I

Pendant les années 80, le comité de Bâle a tablé sur l’établissement de normes internationales sur le capital minimum qu’une banque devait détenir afin de garantir sa stabilité. En  1987, le  « capital adequacy framework »  (accord de  Bâle I) est  proposé par le comité. Celui-ci est validé en l’espace de 2 ans par 150 pays et adapté au cadre juridique de chacun d’entre eux. Le comité  fixe des normes (guidelines) et celles-ci, une fois transposées dans les pays, par consensus, deviennent des “lois internationales”.

Les banques peuvent investir comme bon leur semble mais il est important qu’elles ne fassent pas faillite et qu’elles ne prennent pas de risques excessifs.  Donc, la logique veut que plus la banque investit, plus elle doit avoir de capitaux propres.

Les représentants des États-Unis et des états européens sont arrivé à un accord sur une formule du capital réglementaire, le ratio de Cooke. Ce capital  doit être supérieur ou égal à 8% des actifs pondérés. Par actif, il est sous-entendu crédit accordé aux clients.

• RC est le capital réglementaire (regulatory capital)
•  A est l’actif (asset), ce sont des crédits.
•  w est la pondération (weight)

Au moment de la validation du texte, fin des années 80, les banques des deux côtés de l’Atlantique vivaient des contextes différents. En Europe, la plupart de banques appartenaient aux états et,  si elles étaient déficitaires, les états les renflouaient avec l’argent du contribuable.  Une vague de privatisation a commencé et les accords de Bâle I permettaient aux banques européennes de constituer « un capital privé ».  De leur côté, les banques américaines étaient déjà privatisées et capitalisées. Elles ont demandé l’introduction du tableau de  pondérations pour ne pas être désavantagées dans leurs affaires.

Les valeurs des pondérations  W des crédits sont les suivantes :

• 0% pour les financements des pays OCDE (Argentine, Mexique) soumis à des crises régulières mais terrain d’investissement des banques américaines pendant les années 80
• 20% pour les pays à haut risque comme l’Irak ou l’Angola (non-OCDE)
• 50% pour les crédits immobiliers aux particuliers
• 100% pour tout autres types de crédits (entreprise, gouvernement, autres banques)

Il est important de noter qu’à ce stade les notions de risque et de pricing (valorisation des actifs) sont absentes. La valeur de l’actif est la valeur du crédit. C’est une valeur directe.  Le texte de Bâle I ne faisait que trente pages.  Les publications successives atteindront 350 pour Bâle II et 1000 pour Bâle III.

Accords de Bâle II

De 1989 à 1993, les banques européennes cherchent du capital privé et sont, en conséquence, cotées en bourse. Le but de Bâle I est atteint. Dès 1996, le premier accord commence à dévoiler ses défaillances dans un contexte économique ayant muté.  Il y  a quatre défaillances :

• Les seuls acteurs financiers qui appliquent les accords sont les banques or il existe d’autres établissements de crédit. Une parade de contournement des accords de Bâle I  est la création  d’une division juridiquement indépendante comme par exemple un établissement de crédit-bail. L’arbitrage réglementaire se profile déjà.
• Les banques, au lieu de donner des crédits directs,  demandent à leur clientèle entreprise d’émettre des obligations. Elles échappent donc à la règle du 8% de capitalisation. De même, les banques peuvent investirent dans des dérivés pour lesquels les règles n’existent pas encore.
• La formule de Cooke ne tient pas compte du risque des collatéraux.
• La formule de Cooke ne considère pas la qualité de la contrepartie : bon payeur ou mauvais payeur.

En 2007, les accords de Bâle II en sont à une cinquième version et deviennent une loi applicable à tous les pays membres du BRI. En voici les conséquences.

• Le nouvel accord est appliqué à n’importe quel intermédiaire financier qui gère le risque de crédit : banque, leasing , factoring, crédit à la consommation, participation dans un établissement financier…
• On ajoute toute activité qui contient un risque de crédit : obligations, actions, dérivés, opérations de change. Les banques dont le fond de commerce est la «  corporate finance » et les marchés des capitaux sont sous pression pour augmenter leur capital réglementaire.  Parmi les stratégies de recapitalisation, les établissements peuvent choisir de faire appel au capital des actionnaires, ouvrir le capital à d’autres actionnaires, vendre des actifs, titriser des crédits, voire, acheter une banque qui a beaucoup de fonds propres.
•  W (la pondération dans la formule de Cooke) devient fonction du type de collatéral et du crédit associé à celui-ci. Si avec les accords de Bâle I, le capital réglementaire pouvait être considéré comme un coût fixe, avec Bâle II, il devient un coût variable. La valorisation (le pricing) est aussi une variable dépendante du type de client (client fiable ou mauvais payeur). La gestion du risque devient une compétence très recherchée.

Bâle II se structure en 3 piliers : l’exigence de fonds propres, la procédure de surveillance de la gestion des fonds propres et la discipline de marché. La documentation disponible consacre plus son attention sur le premier d’entre eux.

Le premier pilier, l’exigence de fonds propres, se base principalement sur le risque de crédit. Celui-ci a deux composantes. D’abord le risque de contrepartie (default risk). Ce risque est l’éventualité de ne plus être payé par son débiteur. La deuxième composante est le risque de recouvrement (recovery risk) qui mesure l’éventualité ou pas de récupérer une partie du capital prêté à la contrepartie défaillante.  Plus une banque se protège avec des instruments facilitant le recouvrement (collatéral), plus elle peut assumer  des profils de clients risqués. Le risque de contrepartie se déclenche dès lors qu’il y a un retard de 90 jours dans un paiement. Si le taux de rotation des créances client et des dettes fournisseurs est supérieur à 90 jours, les entreprises devront donc les raccourcir.

Indépendamment de la maturité du prêt ou de l’instrument, le risque de crédit (probability of default, PD) est calculé à un an puis il est recalculé chaque année. Les banques devront connaitre quatre variables (LGD, EAD, MVC et RR) pour chaque client et pour chaque opération de chaque client.  Les impacts sur l’organisation et les systèmes d’information sont évidents.

LGD (loss given default) mesure le risque de recouvrement:

• EAD (exposure at default) est l’exposition au défaut, soit l’actif de la transaction
• MVC (market value of collateral) est la valeur de marché du collatéral
• RR (recovery rate) est le taux de recouvrement

Le ratio de Cooke pour le calcul du capital réglementaire devient le ratio de McDonough où  RWA signifie  risk weighted asset (Ai.Wi).  Les RWA,  ,  du ratio de Cooke sont comptabilisés pour 3 types de risques différents  Wi(crédit), Wj (marché) et  Wk (opérationnel) .

RWA = f(PD;LGD) x EAD où f respecte une loi normale

Expected Loss = EL = PDxLGDxEAD

Le risque de crédit peut être calculé suivant trois méthodes: une approche standard, IRB (Internal Rating-Based Approach), IRB avancée . Le risque de marché peut être calculé avec la méthode VaR (value at risk). Le risque opérationnel peut être calculé avec trois méthodes: BIA (basic indicator approach) , STA (standardized approach) et AMA (advanced measurement approach).

RC est divisé en trois couches (tier en anglais). Tier 1 est l’ensemble de les capitaux propres de la banque (equity, les parts de actionnaires et les réserves). Tier 2 est du capital supplémentaire incluant par exemple des provisions. Tier 3 est la composante requise pour faire face au risque de marché.

Le deuxième pilier est la procédure de surveillance de la gestion des fonds propres au cours de laquelle les banques doivent être capables de prouver l’origine et la validité des calculs du ratio de McDonough. C’est le back testing.  En cas de crise d’un secteur de l’économie, les banque devront prouver que leurs capitaux réglementaires leur permettent de résister aux conditions défavorables.

Le troisième pilier, la discipline de marché , est la mise à disposition  publique d’informations sur l’actif, les risques et leur gestion. C’est de l’information disponible pour les investisseurs avertis.

Après la crise de 2008, en 2009 le comité de Bâle s’est réuni afin de retoucher certains fondements de Bâle II. La nouvelle mouture a été nommée Bâle 2.5. Bâle 2.5 s’est appliqué principalement en Europe à partir de 2011 via la transposition de normes en lois votées par le parlement.  Elles sont connues sous le nom de CRD2 et CRD3 (CRD : capital requirement directive). Les améliorations impactent les risques sur les titrisations et les instruments financiers complexes. Les capitaux hybrides sont diminués dans la constitution de la couche « Tier 1 » du capital réglementaire.  Aussi, dans le domaine des risques de marché, les pondérations sont modifiées.

Bâle III

Bâle II se focalise principalement sur le niveau de capital que les prêteurs d’argent devaient avoir.  Les prêts ont un risque et constituer une réserve permet en principe de faire face à des crises. Bâle III augmente le niveau de ce capital de réserve de base de 2,5% à 7%. En plus de la réforme sur la qualité du niveau de capital requis, Bâle III introduit deux autres axes d’améliorations.

Le premier axe est un effort de réduction de la taille du bilan via une limite sur le volume d’activité en fonction du volume des capitaux propres. Ainsi le ratio sur l’effet de levier (leverage ratio)  contrôle la taille du bilan.

Le second axe est la règle sur la liquidité. Les coffres d’une banque se remplissent au passif  du bilan avec les dépôts des clients et se vident à l’actif du bilan avec les crédits accordés aux clients. Avec le temps, les intérêts sur les crédits reviennent au passif sous forme d’encaissements. Bâle III soumet les banques à des simulations de scénarios de stress de 30 jours et d’un an au cours desquels la possibilité de se refinancer dans le marché interbancaire et de recevoir les intérêts est interrompue.

Quel est l’impact sur le fonctionnement des banques ? La règle sur la liquidité impacte  le  ROE (return on équity). En effet, le ROE diminue puisqu’il est défini comme le résultat net sur le capital disponible. Au numérateur, le résultat net diminue et au dénominateur le capital augmente.  Ceci pousse les banques à chercher ou à retenir plus de liquidité. En conséquence, les activités de cash management et de factoring deviennent complémentaires aux activités  « traditionnelles » de dépôt et de prêt. Plus la relation avec un client est « intime », plus les capitaux resteront au sein de la banque. Autrement dit, si un client regroupe ses activités de cash management avec une banque, au final, les opérations ne seront que du book to book et le besoin en liquidité sera moindre car la liquidité est retenu et ne part pas vers d’autres banques.

La constitution des capitaux réglementaires

La Figure 1 montre l’évolution des capitaux réglementaires entre Bâle II et Bâle III.

Figure : la recomposition des parts du capital réglementaire entre Bâle II et III

Le Common Equity Tier 1 (CET1) est composé de fonds propres (titres émis par la banque conservés sur le long terme), bénéfices non-répartis (retained earnings) et de réserves. Il sera augmenté progressivement  sur plusieurs années (voir calendrier plus bas).

La part « conservation buffer »  doit être mise de côté pour faire face à des périodes de récession. Les banques qui ne le constituent pas ne pourront pas distribuer des dividendes ou des bonus.

La part contrecyclique (coutercyclical buffer) fait partie de la part « conservation buffer » et sera garni suivant la législation de chaque pays. Par contre-cycle, il est entendu qu’en période de “boom”, quand les crédits s’accordent facilement, les banques épargnent. En période de récession, alors que la liquidité s’assèche, la part contrecyclique est utilisée pour accorder des crédits.

La part Tier 2 est composée de   réserves inattendues (undisclosed reserves, revaluation reserves), de  provisions générales, d’ instruments hybrides (ie : Ce type d’instrument a des caractéristiques de dette et de fond propre. Il  exige un décaissement sous forme de coupon et s’intègre après aux fonds propres. Les obligations convertibles en actions à maturité en sont un cas) et d’actions préférentielles (preferred stock).

La part tier 3 disparait dans les accords de Bâle III.

Ici le leitmotiv est “amasser de l’argent de réserve en cas de coup dur”. Certaines banques voient leur rentabilité menacée. Certains analystes prédisent le retrait des banques de certains pans d’activités, l’octroi de plus en plus difficile de crédits ou le basculement vers le shadow banking comme solution de repli vers une rentabilité majeure.

Modification du calcul des risques

La figure ci-après montre les changements dans le calcul des risques entre Bâle II, Bâle 2.5 et Bâle III.

Figure : Modification du calcul des risques (source : Moodyesanalytics)

• Le CVA (credit valuation adjustment) est maintenant calculé. C’est le rajout des pertes potentielles en cas de défaut de la contrepartie.  Avant la valorisation des portefeuilles ne prenait compte que de l’évolution des marchés (risk free-portfolio).
• Les produits dérivés et les pensions livrées (repurchase agreements) sont échangés via une chambre de compensation.
•  WWR (wrong way risk) est maintenant inclu. WWR est la  présence d’une forte  corrélation entre l’exposition et le risque de défaut. Si le montant de la perte augmente  (exposition) de pair avec la probabilité de défaut, le WWR se manifeste.

LCR Liquidity Coverage Ratio

Le LCR couvre la notion de « stress test » pendant 30 jours.  Ce ratio à calculer régulièrement montre que la banque est prête à tout moment à affronter une crise de liquidité pendant un mois.

• Stock d’actifs liquides : réserves auprès des banques centrales, titres commercialisables sur le marché et faisant partie du Tier 1.  Seulement 40% peut être représenté par le Tier 2.
• Le net total des décaissements est  le total des décaissements moins le total des encaissements en situation de stress pendant 30 jours.  Les décaissements augmentent.   Le retrait des dépôts et l’évaporation d’autres éléments du passif sont simulés avec des pondérations par type de client. Les encaissements  diminuent. Les cash-flows habituellement positifs comme les commissions et les paiements d’intérêts diminuent pendant la période de stress.

NSFR  Net Stable Funding Ratio

Le respect de ce ratio permet à la banque de résister à une crise de liquidité qui se prolongerait pendant un an.

• ASF est constitué par le Tier 1 comme les fonds propres, des dettes à long termes, des dépôts à terme. D’autres éléments peuvent être inclus mais diminués avec une pondération inférieure à 1.
• RSF est constitué par des éléments de l’actif  et des engagements hors bilan ayant des maturités supérieurs à un an. Suivant le type d’actif, il y a une pondération particulière .

Ratio de levier

Ce ratio est calculé de sorte à éviter une croissance excessive du bilan. C’est un ratio qui ne se base pas sur des calculs de risques.

Ce ratio est généralement respecté par les banques. Il oscille entre 10% et 40%.

Calendrier

Le calendrier ci-dessous souligne l’application progressive des mesures prises par Bâle III. Bâle II n’a pas été appliqué par les banques américaines. En ce moment, les banques américaines se focalisent dans l’application du Dood-Franck Act. Cependant, elles se conformeront à Bâle III. Le chantier d’application sera plus complexe pour les banques américaines que pour les européennes.

Figure: calendrier de Bâle III

Conclusion

Les accords de Bâle I ont renforcé la constitution du capital réglementaire (CR). Bâle II a introduit 3 piliers. Les risques de crédit, de marché et opérationnels sont pris en compte dans les calculs du CR. A ce premier pilier s’ en ajoutent deux autres, à savoir, les procédures de surveillance et la discipline de marché.  Bâle 2.5 a incorporé des mesures contre les défaillances dévoilées par les évènements de la crise de 2008. Les risques de la titrisation et les expositions sur le trading book devaient être prise en compte. Bâle III  améliore les 3 piliers existants et rajoute des mesures sur la liquidité.  Le comité de Bâle se réunit régulièrement. Les discussions récentes abordent le shadow banking , ce système bancaire parallèle basé sur le crédit financé par des activités de marché et échappant aux normes prudentielles des accords Bâle.  C’est une source de financement alternative mais aussi un mécanisme par où les banques peuvent s’adonner à l’arbitrage réglementaire et diminuer les effets voulus par les accords de Bâle.

références

The post Introduction aux accords de Bâle I, II et III first appeared on In Fine - Le Blog.

Notions de base et principes

• Messagerie au minimum 4 coins, 2 utilisateurs, 2 adhérents, couverts par au moins trois contrats
• Echanges de dialogues structurés formalisés au sein d’applications, qui, lorsqu’elles sont éditées par la norme, ont une portée globale (à tous les adhérents)
• Mise  en œuvre un procédé d’accusé de réception systématique (l’acquittement) qui est garanti par les adhérents. Cet accusé de réception induit l’authentification des adhérents et l’intégrité des messages échangés
• Garantie de l’authentification des personnes physiques liés à un identifiant (le qxban). Le transcodage entre un IBAN et un QXBAN est toujours assuré par l’adhérent émetteur du QXBAN. L’IBAN est ainsi protégé dans le dialogue entre les utilisateurs, même lorsque un message articule un paiement
• Proposition de services à valeur ajoutée : enrichissement du flux, vérification, articulation d’un paiement (le rôle des établissements de paiement est un plus pour l’utilisateur)
• Garantie du respect de règles communes. Il ya une charte des adhérents et un cadre juridique édicté par la banque de France
• Transport par les messages de l’information permettant de réaliser l’action suivante
• Utilisation et accès à     SEPAmail par divers  canaux d’échange de l’information entre un adhérent et son client, l’utilisateur et notamment le moyen de l’authentification de l’utilisateur par l’adhérent
• Fonctionnement en mode canonique avec les infrastructures et les protocoles de messageries électroniques standards. SEPAmail est une messagerie sur internet, le mode d’échange canonique est donc celui de la messagerie électronique, c’est à dire le mécanisme d’échange proposé par le protocole SMTP.

Les services à valeur ajoutée ou les pierres précieuses

Rubis

RUBIS : Règlement Universel Bancaire Immédiat & SEPA (application SEPAmail)

L’application permet de gérer des demandes de règlement, et peut aussi permettre d’initier des paiements correspondant à ces demandes.

La circulation des flux se fait en respectant le modèle 4 coins : créancier, banque du créancier, banque du débiteur, débiteur.

1. Envoi de la demande de paiement comportant
   • Les références de la demande de règlement, qui serviront de références pour le virement (libellé, end2end, ultimate, sur la base des champs du virement SEPA)
   • Le montant
   • Le compte du créancier à créditer
   • D’éventuelles informations complémentaires sur la livraison des biens ou la mise à disposition du service
2. Acceptation par le débiteur en donnant un ordre de règlement à sa banque
3. Génération d’un message de retour en confirmant l’acceptation par le donneur d’ordre (débiteur)
4. virement de fonds réalisé par la banque du débiteur vers la banque du créancier
5. Réception des fonds
6. Contrôle et dénotage du virement, de la confirmation de règlement vis-à-vis de la demande de règlement émise par le créancier

Gemme

GEMME :  Global European Mandate Management & Exchange (Application SEPAmail)

L’application permet d’initier des mandats de prélèvements ainsi que tous les flux autour du prélèvement : pré-notification des échéances, acceptation ou refus d’échéance, acceptation ou refus de l’autorisation de mandat de prélèvement, demande de copie.

Sur ce concept les interactions initiales peuvent se représenter sur le schéma suivant :

1. le flux commercial entre le client et le créancier se conclut par un accord sur le bien ou le service, le mode de paiement par prélèvement et l’échange de l’IBAN
2. le créancier formate un mandat avec le numéro et tous les élements constitutifs dont l’IBAN et donne le tout à sa banque
3. celle-ci le route vers la banque du débiteur facilement avec SEPAmail car elle connait l’IBAN
4. cette dernière met le mandat à disposition du client-débiteur dans la banque à distance ou tout autre canal de son choix (choix de la banque du débiteur). Le débiteur peut donc valider, avec les moyens d’authentification proposés par la banque, le mandat. Le routage vers la banque du créancier puis vers le créancier complétera le processus.
5. le créancier peut envoyer les notifications d’échéances sous un format électronique : l’adresse de son client reste l’IBAN ; le débiteur peut recevoir directement, par sa banque à distance ou tout autre canal mis à disposition par sa banque, les notifications et y répondre rapidement en cas de désaccord
6. un message complémentaire de “Demande de Copie” permet de compléter le dispositif. En effet si un client réclame car il indique ne pas avoir signé de mandat pour un prélèvement, sa banque prend l’IBAN du créancier dans le prélèvement et est ainsi capable de formater un message de demande de copie vers la banque du créancier.

Diamond

DIAMOND : Direct Identity control for Account Management ON Demand.

L’application permet pour un utilisateur SEPAmail de fiabiliser un ou plusieurs identifiants de type IBAN

AGATE

AGATE : A Generic ATtachment Exchange

L’application permet d’envoyer un ou plusieurs courts messages de 140 caractères et une pièce jointe.

La séquence pour l’envoi d’un message générique :

1. l’émetteur transmet de 0 à n chaînes de caractères (encodage ISO) ainsi qu’un contenu indéfini pour la banque de l’émetteur
2. la banque de l’émetteur utilise message SEPAmail SendRequest
3. un accusé de réception du message est envoyé via un acquittement SEPAmail
4. la banque du destinataire transmet à son client le contenu du message via son interface avec le client sans traitement métier du message

IOLITE

IOLITE :  InvOincing LITE

L’application permet de transmettre à un partenaire commercial (client, fournisseur) une facture

Le cœur de cible de IOLITE est la dématérialisation de la facturation, notamment pour toutes les entités de taille moyenne et les cas d’asymétrie coûteuse entre les acteurs :

• des entreprises spécialistes de l’intermédiation sur le web transmettant une facture fournisseur et une facture de commission avant virement du solde ou demande de règlement du solde
• des entreprises désirant transmettre à son client une structure agrégée et détaillée de facturation (facturation de fluide, au poids, au forfait)
• des entreprises facturant à l’acte et cumulant la demande de règlement sur une période

JADE

JADE : Jointed Additional Data & Exchange

L’application permet d’initier un avis de virement en lui joignant un document explicatif, puis le virement, éventuellement en fonction de la réponse attendue.

Voici le diagramme de séquence type de cette application :

un diagrammede séquence type de JADE

On y trouve les acteurs :

• celui qui initie le virement : le donneur d’ordre
• la banque du donneur d’ordre
• celui qui reçoit le virement, le bénéficiaire
• la banque du bénéficiaire

Ce qui donne la séquence d’opérations suivante :

• 1. la génération du justificatif de virement par le donneur d’ordre
• 2. la transmission du justificatif et de l’ordre de virement (il est possible d’utiliser un message SEPAmail JADE CreditTransferAdvise) du donneur d’ordre à sa banque
• 3. la génération du message d’avis de virement CreditTransferAdvise et sa transmission par la banque du donneur d’ordre à la banque du bénéficiaire. Ce message précise la date prévue du virement et si ce virement est conditionné à une réponse et quelle réponse
• 4. un accusé de réception de l’avis de virement est envoyé via un acquittement SEPAmail
• 5. l’avis de virement est distribué par la banque du bénéficiaire à son client

Si le payé répond :

• 6. le bénéficiaire répond avec son interface à sa banque
• 7. la banque du bénéficiaire transmet la réponse sous la forme d’un message CreditTransferReply
• 8. un accusé de réception de la réponse est envoyé via un acquittement SEPAmail
• 9. cette réponse est transmise par la banque du donneur d’ordre au donneur d’ordre

Dans tous les cas :

• 10. le virement est émis à date si les conditions de l’avis initial sont réunies

JASPE

JASPE : Jointed Attached Signed PDF & Exchange

L’application est orientée document. Elle permet à plusieurs acteurs de signer un document (format pdf) selon un parcours défini.

Voici le diagramme de séquence type de cette application pour un parcours simple de signature (un émetteur/signataire et un signataire) :

un diagramme de séquence JASPE pour un parcours simple de signature

On y trouve les acteurs :

• l’émetteur du document et du parcours de signature qui peut éventuellement être lui même signataire du document
• la banque de l’émetteur
• le destinataire signataire du document
• la banque de ce signataire

Ce qui donne la séquence d’opérations suivante :

• 1. l’émetteur génère le document au format PDF à signer, éventuellement avec le formulaire à remplir avant signature
• 2. l’émetteur transmet ce document ainsi qu’un parcours de signature à sa banque pour gestion de ce parcours de signature
• 3. la banque de l’émetteur vérifie le parcours et sa capacité à le traiter (traitement parallèles ou en série, nombre et niveaux des signataires)
• 4. la banque de l’émetteur transmet à la banque du signataire via un message SEPAmail SignatureRequest
• 5. un accusé de réception du message précédent est envoyé via un acquittement SEPAmail
• 6. la banque du signataire distribue le document à signer à son client
• 7. le client signe le document, en remplissant préalablement si besoin le formulaire inclus dans le document
• 8. la banque du signataire transmet à la banque de l’émetteur le document signé via un message SEPAmail SignatureReport
• 9. un accusé de réception du message précédent est envoyé via un acquittement SEPAmail
• 10. la banque de l’émetteur transmet une notification pour chaque retour à l’émetteur si celui-ci a demandé un suivi/pilotage
• 11. la banque de l’émetteur transmet le document final à l’émetteur

Si cela est prévu

• 12. la banque de l’émetteur transmet à la banque du signataire le document signé via un message SEPAmail SignatureCopy
• 13. un accusé de réception du message précédent est envoyé via un acquittement SEPAmail
• 14. la banque du signataire met à disposition de son client le document signé

SAPPHIRE

SAPPHIRE : Security, Authentication, Privacy, Public Key Infrastructure, Highly Innovative, Interoperable, Reliable & Exchange

SAPPHIRE spécifie les conditions d’une authentification d’un client avec sa banque avec la possibilité de signature et plusieurs niveaux dans la sécurisation de l’échange. C’est une proposition fonctionnelle d’authentification permettant la signature numérique.

Sapphire est un protocole permettant d’utiliser :

• un terminal électronique (pc, téléphone portable, tablette),
• une interface applicative hors « banque à distance »,
• le réseau internet
• un dispositif cryptographique (matériel et éventuellement logiciel)

pour :

• s’authentifier sur une prise SEPAmail,
• signer électroniquement (plusieurs niveaux) des messages d’une famille SEPAmail pour l’envoyer sur le connecteur SEPAmail de sa banque
• s’authentifier sur tout autre système de la banque ou un système partenaire

Sapphire vise donc à implémenter une sécurisation maîtrisée du canal internet entre l’utilisateur et sa banque, avec des procédures d’enregistrement (enrollment) utilisant les canaux sécurisés existants.

L’espace de confiance entre un utilisateur et sa banque s’enrichit ainsi d’une prise d’authentification sécurisée utilisant :

• le réseau internet pour le transport
• une application sur le terminal de l’utilisateur
• un certificat permettant une authentification de l’utilisateur (authentification sapphire) puis des données envoyées selon le niveau de service demandé (signature électronique, signature électronique avancée, signature électronique qualifiée)

La messagerie

Le système SEPAmail se compose :

• d’un réseau interbancaire sécurisé assurant le transport de messages structurés conformément aux normes partagées par les utilisateurs de SEPAmail. Le réseau SEPAmail se déploie par l’interconnexion entre serveurs conformes à la norme installés dans chaque établissement adhérent.
• de services métiers à valeur ajoutée, supportés par le système SEPAmail au travers de l’utilisation d’une famille de messages structurés liés à chaque service métier mis en ligne sur ce réseau.

SEPAmail décrit également les connecteurs permettant aux entreprises d’envoyer, de recevoir et de gérer des messages –- ou plus exactement, en termes SEPAmail, des missives – à travers diverses formes d’interfaces : courriel, Web service, et même échange de fichiers.

Les espaces de confiance

Pour assurer une parfaite sécurisation des échanges et des données, SEPAmail repose sur trois espaces de confiance complètement distincts et indépendants :

• L’espace expéditeur – banque de l’expéditeur, dont la sécurité repose sur les systèmes en place : banque à distance et authentification associée, remise de fichiers …
• Le réseau interbancaire SEPAmail dont la sécurité repose sur :
  • Un nom de domaine unique géré par le « scheme-manager » et associant l’adresse BIC.sepamail.eu à la bonne adresse physique de routage de la banque possédant le BIC
  • Une déclaration au scheme-manager de la clé publique qui sera utilisée par S/MIME, déclaration faite en même temps que la fourniture de l’adresse IP de la banque
• L’espace banque du destinataire – destinataire, dont la sécurité repose également sur les systèmes en place : banque à distance et authentification associée, remise de fichiers, …
• Il y a un certificat S/MIME de signature et un certificat S/MIME de chiffrement par BIC et par application SEPAmail.

La structuration du système

L’élément de base pour les échanges d’informations, dans SEPAmail, est la missive. Quel que soit le canal d’échange, et quels que soient l’expéditeur et le destinataire, toutes les informations circulant dans le système sont systématiquement structurées en missives. Il existe quatre types de missives, qui seront décrites en détail par la suite :

• la missive nominale, qui sert d’acheminement à un message
• la missive d’acquittement, élément essentiellement protocolaire qui permet notamment à l’expéditeur d’être sûr de la réception des informations transmises
• la missive de service, permettant d’échanger des commandes et des réponses entre des éléments actifs du système. Elle ne peut pas être utilisée en interbancaire.
• la missive d’interfaçage (SMAPI), permettant à l’éditeur d’une solution SEPAmail de donner accès à des fonctions internes de sa plate-forme. Elle ne peut être utilisée qu’en intrabancaire.

La missive est sécurisée par des mécanismes de signature et de chiffrement. Elle peut être vue comme une enveloppe, dont le contenu peut être quelconque, mais n’est accessible qu’au destinataire. Dans la plupart des cas, et notamment dans le cas des missives nominales, le contenu d’une missive est un message SEPAmail. Le message contient des informations relatives au service mis en jeu, la nature de ces informations variant bien entendu selon le message. L’ensemble des éléments de SEPAmail, missives et messages, sont des structures XML. Tous les éléments sont décrits par des schémas XML précis, s’appuyant, dans la mesure du possible, sur la norme et le dictionnaire de données ISO 20022. Enfin, les missives sont échangées, entre les acteurs du système SEPAmail, par le biais d’un mécanisme d’échange. Trois mécanismes, qui sont détaillés par ailleurs, sont actuellement définis et implémentés dans le système :

• le courrier électronique
• un web-service
• un système d’échange de fichiers.

Le schéma ci-dessous récapitule les éléments de structure du système SEPAmail:

Rappel S/MIME

• Le standard S/MIME étend le format de courrier MIME pour permettre, au travers de plusieurs mécanismes cryptographiques, de chiffrer et signer les différents composants d’un message. Il s’applique donc directement sur le contenu du message et non sur le canal de transport de ce contenu.

• La clé de session est insérée dans l’en-tête de chaque partie S/MIME, après avoir été chiffrée à l’aide de la clé publique de chacun des destinataires. Ainsi ces derniers pourront par la suite déchiffrer, à l’aide de leurs clés privées, la clé de session et accéder au contenu de la partie S/MIME.

• Par ailleurs, la signature d’une partie S/MIME est générée à l’aide de la clé privée de l’expéditeur. La vérification de cette signature à l’aide de la clé publique de l’expéditeur permet de garantir au destinataire l’identité de celui-ci et de contrôler l’intégrité de la partie S/MIME.

Références

The post SEPAMAIL first appeared on In Fine - Le Blog.

Historique

Lors de la sortie de la version 2.1 de Google Web Toolkit, une nouvelle API : RequestFactory a fait son apparition. Cette API a été conçue dans le but de simplifier l’interaction et la manipulation de données côté serveur depuis le client (javascript).
Auparavant, les développeurs utilisaient essentiellement GWT-RPC pour les appels de service impliquant des manipulations de données côté serveur.
Etant donné que le code côté client interagit avec du Java côté serveur, GWT-RPC fournit nativement
un mécanisme de sérialisation de données puissant. Cependant, cela ajoutait également un certain nombre de contraintes. Entres autres, le fait que tout objet échangé entre le client et le serveur devait être Serializable (au sens GWT), l’utilisation du pattern DTO qui induisait une redondance du code métier serveur au niveau du client etc.

Différence entre GWT-RPC et RequestFactory

La différence fondamentale entre les deux API réside dans l’orientation. GWT-RPC  est une API orientée service. A la base, elle permet d’invoquer des méthodes distantes d’une couche service pour interagir avec les données.

RequestFactory quant à elle est une API orientée donnée. Elle invoque directement des méthodes exposées non pas sur une couche service, mais sur les entités métiers (selon la terminologie GWT) elles-mêmes. C’est comme si on rendait les données serveurs disponibles au niveau du client. Les méthodes invoquées sont alors les méthodes des objets métiers.

Concepts de base

RequestFactory se base sur la notion de Proxy. Pour effectuer des opérations sur les données côté serveur, il définit un objet proxy qui “représente” cet objet serveur au niveau du client. Ce proxy est en fait une “interface” qui définit l’ensemble des méthodes qu’on voudrait exposer sur l’objet métier lui-même. Pour déclencher l’exécution d’une action sur l’objet côté serveur, il suffit de l’invoquer sur l’interface du proxy et RequestFactory se charge de l’envoi de la requête ainsi que de la sérialisation/déserialisation des données. Il est à noter qu’il utilise un protocole de sérialisation qui lui est propre et qui est différent de GWT-RPC.

Quelques règles à respecter

Le fonctionnement interne de RequestFactory impose quelques contraintes au niveau des classes métiers dont :

L’objet métier doit avoir un constructeur sans argument

la nécéssité d’avoir un champ VERSION dans la classe métier (annoté @Version en JPA). Ce champ permet à RequestFactory de tester si un objet a changé d’état.

Chaque Entité doit également disposer d’une méthode statique permettant de retrouver une instance de l’objet par son identifiant. Par exemple, pour l’entité de type Person, ce sera :

public static findPerson(Long id) {

// retrieving object by Id using EntityManager

}

Cas d’utilisation

Supposons alors qu’on ait un objet métier Personne dans notre application. Les objets de cette classe sont déstinés à être sauvegardés dans une base de données. On les appelle tout naturellement des “Entités” dans RequestFactory. On supposera que la persistance est gérée par Hibernate dans notre application et que tout a déjà été configuré (hibernate.cfg.xml, etc.). Nous avons donc dans notre domaine, le code suivant :

@Entity public class Person {
  @Id
@Column(name = "id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long id;

@Version
@Column(name = "version")
private Integer version;

@Version
@Column(name = "name")
private String name;
@Column(name = "surname")
private String surname;

  @JoinColumn(name="address_id")
  Address address;

  public Personne() { }  // Getters and setters ...

}

Après avoir défini notre objet métier, on va donc lui adjoindre un “Proxy” qui sera une représentation de cet objet métier côté client. RequestFactory se charge alors de
propager les opérations invoquées sur les proxy vers les entités côté serveur. Il est également important de noter que RequestFactory envoie seulement les différences entre
ce qu’il y a côté serveur et côté client, économisant ainsi la bande passante.

Entity Proxy

Une entity proxy est un proxy qui comme son nom l’indique, représente une entité côté serveur. Pour la définir il suffit de créer une interface qui étend EntityProxy
et d’indiquer la classe métier qu’il représente via l’annotation @ProxyFor.

@ProxyFor(Person.class)
public interface PersonProxy extends EntityProxy {
public Person() { }
// Les méthodes exposées ...
public String getName();
public void setName(String name);
public AddressProxy getAddress();
public void setAddress(AddressProxy address);
// Les méthodes exposées ...
public String getName();
public void setName(String name);
public AddressProxy getAddress();
public void setAddress(AddressProxy address);
}

Les méthodes qu’on a défini dans le proxy sont les méthodes “invocables” sur l’objet métier. Ainsi, si on veut restreindre l’appel à certaines méthodes de l’objet métier
côté serveur, il suffit de ne pas l’indiquer dans le proxy. Ici par exemple, on a omis les modificateurs de Surname, ce qui veut dire qu’on ne pourra pas invoquer la méthode
de modification du prénom depuis le côté client.
Remarquons également que si une Entité A possède une référence vers une autre Entité B, les signatures du proxy AProxy feront référence à des BProxy (dans notre cas, AddressProxy).

Le lien entre le client et le serveur : RequestFactory

Après avoir défini les entités et leurs proxy, on crée maintenant la RequestFactory elle-même. C’est une interface qui comme son nom l’indique va créer les “stubs”
permettant la communication entre le client et le serveur.

public interface ApplicationRequestFactory extends RequestFactory

{

    PersonRequest personRequest();

    AddressRequest addressRequest();
}

PersonRequest et AddressRequest sont nos stubs pour les opérations concernant respectivement les entités Person et Address.

@Service(PersonServiceDAO.class)
public interface PersonneRequestContext extends RequestContext {

Request<List<PersonProxy>> getPersonList();

Request<PersonProxy> findPersonById(Long id);

}

Notons que les stubs utilisent toujours Request comme type de retour, où X est le paramètre de retour de la méthode de service.
Le stub doit nommer via une annotation, la méthode qui implémente les services côté serveur. Ainsi, dans notre exemple on a deux méthodes qu’on peut invoquer côté serveur
pour les entités de la classe Personne : on peut retrouver la liste complète ou encore retrouver une Personne par son identifiant.
On pourrait imaginer une classe service comme la suivante ( j’ai omis volontairement toute la partie de gestion des exceptions liées à la persistance des données pour une raison de lisibilité) :

public class PersonServiceDAO {

public List<PersonProxy> getPersonList()
  {
      List<Person> personList = new ArrayList();
      EntityManager entityManager = PersistenceManager.getEntityManagerFactory().createEntityManager();
      try {
          personList = entityManager.createQuery("FROM Person").getResultList();
      } catch (Exception e) {
          e.printStackTrace();
      }
      return personList;
  }

public Personne findPersonById(Long id) {
      EntityManager entityManager = PersistenceManager.getEntityManagerFactory().createEntityManager();
      Person person = null;
      try {
          person = entityManager.find(Person.class, id);
      } catch (Exception e) {
          e.printStackTrace();
      }
      return person;
  }
}

Utiliser RequestFactory

Enfin la dernière étape pour l’exécution de RequestFactory est de l’invoquer depuis le code client. Dans un premier temps, on doit initialiser le bus d’évènement. Une manière de procéder c’est de faire l’initialisation dans le constructeur de la classe dans laquelle on va utiliser RequestFactory.

public class OurClassWindow {
final EventBus eventBus = new SimpleEventBus();
ApplicationRequestFactory requestFactory = GWT.create(ApplicationRequestFactory.class);

public OurClassWindow() {
// Initialize event bus
requestFactory.initialize(eventBus);
}

}

Le mécanisme d’appels dans RequestFactory est très similaire à ce que l’on retrouve dans GWT-RPC. Après avoir retrouvé la requestContext, on invoque la méthode tout en
passant un callback qui sera appelé par RequestFactory au retour de la fonction.

Receiver<List<PersonProxy>> receiver = new Receiver<List<PersonProxy>>(){
@Override 	public void onSuccess(List<PersonProxy> response) {

// Do something with the response from RequestFactory

} };

requestFactory.personRequestContext.getPersonList().fire(receiver);

receiver ici, représente la méthode callback qui sera appelée au retour de la fonction. Comme dans GWT-RPC, il dispose de méthodes onSuccess et onFailure permettant de gérer
les cas de réussite ou d’échecs après l’appel.

Conclusion

Si vous avez déjà codé en GWT, vous savez à quel point il est fastidieux d’écrire des services uniquement pour ramener des données stockées en base  : RequestFactory est une manière élégante simple pour effectuer à moindre coût des appels vers un backend. L’API et la mise en oeuvre sont similaires à ceux de GWT-RPC, il est ainsi très facile de l’appréhender même si on est habitué à GWT-RPC.

pour aller plus loin : https://developers.google.com/web-toolkit/doc/latest/DevGuideRequestFactory

The post RequestFactory ou comment faire du CRUD avec GWT first appeared on In Fine - Le Blog.

La connaissance acquise est essentiellement métier et ergonomique (pour autant que la technologie employée est maitrisée). Si pour les aspects ergonomiques, un prototypage graphique peut (ou devrait) être proposé, comment faire de même avec le code sous-jacent, le code représentant les connaissances métier ?

Un première approche se base sur un processus itératif, suivant un processus dit “agile”. Cela est toutefois rarement compatible avec des langages de développement “classiques”. En effet, il faut alors prendre très tôt des décisions majeures et structurantes. De plus les changements deviennent de plus en plus difficiles et coûteux. Il conviendrait donc de pouvoir poursuivre le plus tardivement possible la phase de conception, ce qui peut apparaître contradictoire avec cette approche “agile”. De plus, l’expérience montre que même les meilleures des conceptions ne peuvent prévenir de nécessités de correctifs en phase de réalisation.

L’idéal serait donc de pouvoir disposer d’un langage tout à la fois de spécification tout en étant exécutable pour pouvoir valider cette même spécification à travers des cas de test. Cela est rendu possible par des langages de type “règles métier”. En effet, ceux-ci permettent pour la plupart de construire des modèles objets (dits “BOM”) de façon souple, voire dynamique, tout en proposant (plus ou moins automatiquement suivant le Business Rule Management System utilisé) un langage de type DSL permettant d’exprimer et d’exécuter des règles métier s’appliquant sur ces objets.

À noter que les principaux BRMS proposant une couche d’interfaçage entre le code décrivant les règles et le framework sous-jascent (Java, .NET, xml, Cobol, etc.), il est tout à fait possible de ne faire le choix de ce(s) framework(s) (plusieurs pouvant cohabiter) que tardivement en fonction des contraintes finales de l’application à développer.

On s’aperçoit également que cette technologie permet de gérer beaucoup plus facilement les cas particuliers. En effet, ces “cas” sont en général caractérisables par un ensemble de contraintes, pouvant être soit directement exprimées au niveau des règles, soit être gérées par le ruleflow. De plus, le fait d’exprimer clairement le domaine métier au sein de règles fait ressortir beaucoup plus facilement ces cas “hors normes”.

Enfin, il est bien rare que la première mise en production d’une application soit la dernière pierre de l’édifice. Les phases de maintenance et de migrations sont primordiales dans la vie d’un logiciel. Des correctifs et évolutions sont donc à prévoir. Ici aussi, les points soulignés ci-dessus (changement de framework sous-jascent, traitement des cas particuliers, etc.) pourront être mis à profit. Avec de plus un avantage décisif par rapport aux langages informatiques traditionnels : le code des règles étant tout à la fois le code exécuté (et donc évoluant avec les mises à jour) et les spécifications de l’application, il y a alors garantie de non divergence entre ces deux aspects, ce qui bien qu’essentiel pour la maintenance est rarement le cas pour la plupart des applications informatiques.

En conclusion, l’usage d’une approche “règles métier” permet de changer radicalement le mode de développement d’applications informatiques, tout particulièrement en permettant de retarder les prises de décisions au moment où la connaissance du sujet est enfin suffisamment avancée, tout en facilitant les ajustements rendus nécessaires dans les phases ultérieures du projet.

The post Ou comment reporter à plus tard… first appeared on In Fine - Le Blog.

Il existe plusieurs degrés de l’offshore, en fonction de la distance géographique avec la France. Avec l’offshore, les pays qui hébergent les services sont très éloignés de la France, comme peuvent l’être la Chine ou l’Inde. Quand les délocalisations concernent des pays plus proches, comme ceux d’Europe de l’Est, ou du Maghreb on parle alors de Nearshore, qui est parfois également utilisé pour les délocalisations vers des régions françaises moins chères. L’onshore consiste à employer le personnel étranger au sein des établissements français, à des conditions qui sont proches de celles du pays d’origine. En France, l’offshore informatique est principalement concerné par la délocalisation des prestations en Inde, parfois associée à des externalisations des services. A long terme, l’offshore peut représenter 10% à 15% des services liés aux technologies de l’information.

Au travers de l’exemple de La Société Générale Global Services Center (SG GSC)  qui existe depuis l’an 2000, l’offshore des services prend tout son sens. SG GSC  propose des services de recherche et développement logiciel, de gestion de projets et d’assistance technique. L’objectif est de créer à Bangalore un centre de connaissance IT pour l’ensemble de la Société Générale, en y incluant les meilleures pratiques utilisées dans le monde de la banque.

Pourquoi les entreprises délocalisent-elles ?

Les principales raisons qui poussent les entreprises à délocaliser sont : la réduction des coûts, l’obtention de compétences indisponibles, une amélioration de la qualité des prestations  et l’occasion d’implémenter des normes de conformités. En Inde, plus de compétences, que ce soit en variété ou en quantité, sont disponibles pour un coût inférieur à celui nécessaire en France. Ceci permet d’atteindre des objectifs de qualité, de charge de travail et d’organisation sans augmenter les dépenses, et permet de libérer des ressources en France pour des activités à plus forte valeur ajoutée.

Quelles sont les difficultés rencontrées par les équipes ?

Les principales craintes liées aux délocalisations sont le risque de la dégradation de la qualité de service, la difficulté du pilotage d’une activité dispersée, le respect des exigences réglementaires, la publicité négative induite par la suppression de certains postes en interne, la sécurité des données. Ces différentes craintes découlent des expériences négatives que certains ont vécues lors de tentatives de délocalisations ratées. Ainsi, ces tentatives échouées peuvent être les conséquences de mauvaises pratiques ou de difficultés qui ont mal été appréhendées. Par exemple, la barrière de la langue est plus difficile à gérer qu’il n’y parait. L’anglais est bien entendu maîtrisé par les équipes françaises et indiennes, mais une conversation téléphonique grésillant entre les deux équipes peut s’avérer compliquée.  Les différences culturelles ne sont pas négligeables, car pour les indiens, la frontière entre la vie privée et la vie professionnelle est bien différente de celle présente en France. Les indiens ont une tendance à toujours répondre positivement à une question, pour ne pas frustrer leurs interlocuteurs, ou juste pour indiquer qu’ils ont bien compris la question. La communication est plus compliquée à distance, ce qui demande plus de formalisation et de structuration qu’au sein d’une équipe située uniquement en France. Ces besoins de formalisation demandent beaucoup de travail du coté Français, et représentent une charge de travail que les personnes ne sont pas habituées à avoir. De plus, les différents moyens de transport et de communication, ainsi que le surcoût engendré par la gestion de projet et les cadres expatriés, augmentent les dépenses au delà des simples salaires des ingénieurs indiens.  Par ailleurs, il faut prendre le temps  d’assurer un suivi suffisant pour vérifier la qualité fournie des services.

Il faut également bien considérer les effectifs distants comme faisant partie à part entière de l’équipe. Ainsi, 20% des projets d’offshore n’aboutissent pas, à cause d’un manque de suivi ou de qualité dans le processus de migration des activités

Quel est le bilan économique et humain de l’Offshore ?

La spécialisation des pays offshore est inévitable et la culture de la complémentarité plutôt que de la différence entre les pays est bénéfique pour tous.  Ainsi, les compétences d’analyse et de conception, et celles qui sont proches du cœur de métier du client, et qui demandent des compétences dans ce domaine, gagnent à être effectuées en France, même si cela demande un surcoût par rapport à des ingénieurs indiens. Par contre les compétences à plus faible valeur ajoutée peuvent être délocalisées et sont associées par certains à des activités moins intéressantes. Les compétences qui sont développées en France sont celles de gestion de projet, d’expertise métier ou de qualité fournie au client, ce qui permet des emplois plus variés pour ceux qui conservent leur emploi. Ainsi, les sommes économisées retournent aux autres salariés qui montent en compétences ou en responsabilités.

Existe-t-il des alternatives à l’Offshore ?

Se mettre à l’écart de la délocalisation est le risque de laisser les sociétés de services informatiques indiennes remporter les contrats de prestations des clients français. Souvent beaucoup plus structurées que les sociétés européennes, avec des certifications, les SSII indiennes sont en passe de devenir des multinationales de premier plan. Cependant, les délocalisations ne sont pas l’unique solution pour baisser les coûts. La réduction de la sous-traitance et une intégration forte des équipes, ainsi la mutualisation des ressources permettent d’obtenir un levier d’économies importantes.

Comment se positionner face à l’Offshore ?

Pour pouvoir rester compétitif et converser les seuls postes à valeur ajoutée qu’il restera, il est utile de rester à l’écoute des besoins des clients, pour développer les compétences qui leur sont utiles sur place. Par ailleurs, une remise en cause permanente et une évolution de ses compétences est nécessaire pour rester compétitifs et prendre de l’avance sur la concurrence.  L’offshore permet de participer à la construction des pays en voie de développements en leur apportant un savoir-faire et en gagnant des marchés économiques importants. Les entreprises des pays développés se doivent, quant à elles, d’investir dans l’innovation et la recherche et développements afin de rester leader et de continuer leur rôle de moteur de l’économie mondiale.

The post L’offshoring: le nouveau mal du siècle? first appeared on In Fine - Le Blog.

The proposed rules to answer that question are not only based on technical aspects of BRMS, but also on organizational ones. In fact, those organizational aspects are often more important than the technical ones in the adoption of BRMS. Of course, those rules are not well formalized and their “Right Hand Side” (“then” part) may vary depending on the case. However, we hope that the following table could help in choosing or not a BRMS to develop an application.

The pluses and minuses of using BRMS:

Of course, that table is not complete nor rigid and your comments to improve it are welcomed.

The post BRMS, But When? first appeared on In Fine - Le Blog.