LostCoins Explorer pre-launch

LostCoins Explorer  is an online service helping to recover stolen Bitcoins.

LostCoins Explorer Transactions Screenshot
LostCoins Explorer Transactions Screenshot

Bitcoins owners can lose their Bitcoins because of scam or hack of companies managing their Bitcoin wallet.

Bitcoin blockchain is a public ledger so you can browse your Bitcoin address transactions history and track where your coins moves. Lostcoins Explorer provides an adapted transactions explorer for this purpose. It’s already available for free in early release here.

Unfortunately Bitcoin address are mostly anonymous so when you find your coins final location you need to investigate on last address owner or wait for a new transactions to another address.

That’s why we are working on next steps of recovering process :

  • monitor address
  • lawyers supports for recovering mandate

(as very first step, we also need to  check victim initial ownership)

You can register to LostCoins Explorer Mailinglist to keep in touch about this service.

Mise en conformité RGPD

Le RGPD (Règlement Général de la Protection des Données) est appliqué depuis le 25 mai 2018.

Dans le cadre d’une mise en conformité JPCA propose d’autoriser ou refuser la conservation des données personnelles récoltées depuis ses sites web, applications ou lors de rencontre comme des manifestations ou des réunions de travail.

Pour les demandes d’opposition ou de modification vous pouvez utiliser l’adresse dédiée rgpd@jpca.fr.

Pour plus d’information vous pouvez consulter notre politique de confidentialité ou nous contacter sur l’email dédié : rgpd@jpca.fr.

Software Solution Project Planning

project_phasesThis article is an extract of the Software R&D Best Practices training, it presents how the project manager should handle a software solution project planning and rollout.

Project planning

The project planning preparation is divided in 3 sub-projects.

  • Plan the pre-study phase.
  • Plan the project from study to delivery
  • Plan the maintenance phase

The pre-study phase must be planned itself in an autonomous way because the project may finish if there’s no agreement on the scope, duration, cost and quality are found between the provider and the customer.

The maintenance phase is planned after the customer accepetance meeting (ie the final payment but eventually the warranty). It’s a recurrent activity phase with mini-projects to be planned on a continuous flow basis up to the maintenance phase end that depends on product life time (or contract guarantee) duration and scope

The remaining project phases, from study to delivery will be planned during the pre-study and finalized at it’s end because without a completed and validated solution requirements document, the project manager does not have enough stable information to produce a realistic project plan.

Project planning steps

The project planning can be done with following steps:

  1. Define project work breakdown
  2. Estimate project tasks workload
  3. Assign resources to tasks : check/ask for resources availability
  4. Identify project risks
  5. Determine project risks & events buffer
  6. Determine project milestones
  7. Iterate on scope, milestones, cost and quality with customer, manager, team and quality assurance officer

These steps should be done in the proposed order in a Gantt chart like this one:

project_wbsProject workload estimation

The project workload estimation (cost and duration) should be based on implementation workload (development, integration, unit tests and software documentation writing) done in the build phase.

The study workload, test workload (including test preparation, test runs and issues fixes), delivery workload and project management workloads are deduced from the implementation workload.

The implementation workload is deduced from solution requirements document (contains use cases, logical architecture, integration flows, business rules, software documentation to be delivered and other non business requirements)

The development workload can be estimated with an in-house method or standard method like Functional Points or COCOMO.

An estimation table about how to spread the total workload from the implementation workload in the build phase is provided in the Software R&D Best Practices training.

Tag & branches policies

I like to dig in github for libraries and other useful components to add in a project I’m working on. I’m much more experienced on Subversion than Git, the trending version control system. Git success is claimed by it’s strong branches features and it’s distributed repositories with push and pull, specially usefull on open source project but, when looking on most open source repositories in github i didn’t see a meaning full use of tag and branches. That’s why I decided to create this article.

I propose here what is, IMHO, a good way to use tag and branches, on a software project context with build/delivery, and maintenances of several release in a software R&D project.

A version control system repository must used for each software product or solution. Several release or maintenance project on the same software should share the same central repository.

The root directory containing all the delivery content is tagged.

At least each delivery to customer or other external teams are tagged. The tag name follows a tag rule name like Apache versioning or Semver (for me, the first digit should be trigger by marketing needs).

Each maintained software release must have a branch created just after it’s offical delivery.

This figure shows an example of branches and tags on a software products built and delivered in several iterations (or Scrum sprints) and then maintained in several version, like when several customer are using differents differents version as operating systems.


  • 1.0.0 to 1.0.4 where delivered to the customer as iteration deliveries, 1.0.3 was not delivered because of a NOGO after customer acceptance review
  • 1.1 release is maintained in a new maintenance branch for a customer guarantee since 1.1.4, while 1.2 released are done on the same branch as 1.1 and 1.0
    • On 1.1 maintenance, after 1.1.5 maintenance release delivery, 3 patches where delivered. 1.1.6 maintenance release includes those patches making them deprecated for 1.1.6 and next 1.1 maintenance release
    • Issues fixed in 1.1 maintenance branches should be merge in 1.x and maybe 1.3.x branches
  • 1.3.x started on a new branch because significant design changes where done (1.x branch can now be used for maintenance for 1.2 maintenance
  • 2.0 start release starts from scratch (avoiding commits and tags on master is an usual practice)

The « dev/ » at the bottom left corner stands for the directory where all the delivery content source files are stored : source code, configuration files, samples,  delivered documentation… You Should have another directory at same level, lets call it « doc/ », where all undelivered elements are stored  : project documents, internal technotes…

I will describe deeper what these directory content in another article. If you can’t wait, you can have the full picture, with much more information like project milestoner, or server environments in the Software R&D Best Practices training.

Augmenter la valeur du système d’information

Je vous conseille la lecture du document Augmenter la valeur du système d’information qui décris ce que doit être la MOA du SI.

Voici un résumé de chapitres qui traitent du choix entre make / buy / run et la prise en compte des coûts d’acquisition (CAPEX) et de fonctionnement (OPEX) dans le choix d’une solution informatique.

On parle en gestion de projet d’analyse de décision MAKE-BUY. En fait, lorsqu’il s’agit d’informatiser des processus métier de l’entreprise, il y a désormais une troisième option à prendre en considération la location :

  • FAIRE (MAKE) : Développer en interne
  • ACHETER (BUY) : Intégrer des logiciels tiers
  • LOUER (RENT) : Souscrire à une offre en mode SaaS

Les raisons initiales de l’investissement informatique sont un facteur déterminant de la stratégie d’achat. Par exemple :

  • le développement métier, lorsque l’activité de l’entreprise doit croitre ou être redéployée sur d’autres marchés
  • la gestion de l’obsolescence, lorsque les outils actuels ne sont plus adaptés, qu’ils coutent de plus en plus cher à maintenir et à utiliser
  • les contraintes réglementaires, lorsque que le cadre légal de l’entreprise change et qu’il nécessite des adaptations

Le schéma ci-dessous donne un aperçu des stratégies d’achat recommandées en fonction du besoin initial :

Ce que nous dit ce schéma c’est que pour développer son activité commerciale, il est préférable d’acquérir durablement un outil informatique. L’achat d’un logiciel ne facilitera pas la distinction de son offre c’est pour cela que le MAKE est préférable… à condition d’avoir le savoir faire (maitrise d’œuvre) ou à minima le savoir faire faire (maitrise d’ouvrage).

Le schéma ci-dessous informe sur les conséquences de chaque stratégie d’acquisition :
strategie_consommationEt enfin un dernier schéma sur la répartition des coûts d’acquisition et d’exploitation d’une solution logicielle dans le cas d’une acquisition de type MAKE.


La maintenance d’une application constitue environ 60 % du coût de sa vie. Dans ces 60%, 40 % concerne de la maintenance évolutive, la maintenance corrective étant aux alentours de 17 %. Dans le cas de l’intégration de logiciels tiers (BUY), la part du build, tout comme la phase d’étude est généralement moins élevée. Ce bénéfice n’est toutefois pas toujours compensé par le coût des licences. Ainsi, en considérant les licences, c’est à dire le coût d’usage de l’application, comme ceux de fonctionnement en exploitation (RUN), on reste sensiblement dans les mêmes tendances : Ce qui coûte cher, c’est l’usage. Dans le cas d’une location de logiciel (RENT / SaaS) presque tout les coûts sont remplacés par l’abonnement. C’est séduisant mais en plus des inévitables coûts d’intégration de la solution SaaS au SI, il faut avoir conscience des conséquences de ce type de solution comme le révèlent les courbes du 2nd schéma.

Un projet réussi doit satisfaire les critères de périmètre fonctionnel, coût, délai et qualité de la solution. Cette qualité s’exprime d’abord sur le coût qu’impose la solution logicielle sur le récurrent (fonctionnement en exploitation ou RUN) et la rigidité qu’il lui amène (évolutions, corrections).

Alors comment améliorer la valeur de son système d’information ? Quelques pistes en lisant Augmenter la valeur du système d’information de Franck Rinaudo.

L’importance de la modélisation dans les entreprises

ceisarLe CEISAR à fait paraitre un article sur l’importance de la modélisation et de la place des objets metier dans la transformation du SI d’une entreprise à l’occasion d’un partenariat avec Praxemehttp://www.ceisar.fr/actualites-et-evenements/detail-de-l-actualite/back/1/article/ceisar-praxeme.html
J’ai adhéré à l’association Praxeme Institute début 2013 suite à une formation en Business Architecture & Transformation mais lorsque je parle de Praxème peu de collègues connaissent :  TOGAF et Urba-EA sont des méthodologies plus connues. Alors voici un petit résumé de ce que je considère de plus novateur dans Praxème.
Praxeme sépare la partie métier (ou Business Architecture TOGAF) en 3 « aspects » :
      • l’aspect sémantique où sera défini le modèle métier  : modèle de donnée orienté objet
      • l’aspect pragmatique  ou sont définis les processus métier, organisation, jargon, habitude
      • l’aspect géographique : pour les différences juridiques, culturelles, les distance inter-sites et autres décalages horaires qui méritent d’être pris en compte.


L’aspect sémantique défini le modèle métier, plus pompeusement le « coeur de métier » ou « le savoir métier » :
  • les objets métier mais pas les processus métier ni l’organisation qui porte dessus
  • les règles métier indépendamment de la façon dont l’activité métier est pratiquée dans une organisation
  • les différents états des objets et les transitions autorisées (cycle de vie, règles de gestion)
C’est une documentation unique et partageable avec plusieurs organisations de l’entreprise (ex: filiales étrangères).
Souvent après ces explications ce n’est pas encore assez  clair pour le néophyte alors voici un exemple que j’ai consolidé à partir de plusieurs messages d’une discussion entre adhérents de l’association Praxeme :
2042Lorsque l’on travail avec des organisations (quelles soient gouvernementales ou privées) on est aussi confronté à la volonté de ces organisations à résister à tout changement et à légitimer leur existence dans leur forme actuelle. Donc, inconsciemment, a leur volonté de modéliser des objets pragmatique en au lieu des objet sémantiques. Prenons la feuille de déclaration de revenus (c’est l’époque…) le piège consisterait à modéliser l’objet métier « déclaration 2042 »  plûtot que les objets métier « revenu », « contribuable », etc. : un modèle uniquement pragmatique (avec l’objet métier 2042) ne sera applicable qu’en France, et rendra difficile la transformation de la gestion des impôts (comme par exemple la mise en place de prélèvement à la source) alors qu’un modèle sémantique (avec des objets métier moins lié à l’organisation actuelle mais plus à la « réalité » : revenu, contribuable, etc.) est indépendant de l’organisation existante et potentiellement applicable dans d’autres pays.
Pour le reste de la méthode (les aspects logique, logistique et physique) c’est plus « classique » ont retrouve les couches logique/fonctionnelle, applicative, infrastructure/technologique d’Urba-EA ou TOGAF. L’Organum par exemple, reprend les idées de l’Architecture Repository TOGAF.
Un regret personnel : le latin est utilisé pour nommer différents éléments de la méthode et cela a été volontairement choisi par soucis d’universalité mais je trouve que cela apporte de la confusion à beaucoup de personne peu habitué à cette langue.
Pour plus d’information sur l’aspect sémantique voir http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf


TOGAF, la belle à marier

Les frameworks d’architecture d’entreprise français tels que Urba-EA et Praxème sont peu connus à l’international et parfois opposés à tort aux frameworks anglo-saxons comme le célèbre TOGAF auquel je viens d’être formé.
TOGAF est orienté activités de l’architecte : il est fort sur ce sujet avec des check lists de quoi faire à chaque étape d’un projet par exemple.  Certains trouverons aussi des « manques » sur les méthodes et le formalisme a appliquer à chaque phase d’un cycle projet TOGAF, mais ces manques sont volontaires pour laisser la place au « comment faire » de ces phases à d’autres méthodes. Ces méthodes doivent d’ailleurs être choisies en phase préliminaire et référencées dans la « reference library » de l’ « architecture repository », .
Par exemple PMBOK peut être utilisé dans les phases F et G du cycle de transformation du SI de l’ADM (la rosace ci-contre).
L’un des objectifs de la phase préliminaire de l’ADM est d’adapter l’ADM au contexte d’une entreprise mais aussi à d’autres frameworks, outils et formalisme.

Lors de phase préliminaire de l’ADM il est conseillé d’adapter la démarche, et globalement tous les éléments du framework, au contexte de l’entreprise.


C’est donc en phase préliminaire que l’on peut décider d’appliquer Urba-EA ou Praxème à TOGAF.
Christophe Longépé aborde ce sujet au chapitre 11.3.3 de l’ouvrage « Le projet d’urbanisation du SI » 4eme edition (ISBN 978-2-10-052883-7) je n’en parlerais donc pas ici…
Je viens du développement et de la modélisation orienté objet, et, mon plus grand regret est que dans TOGAF  l’approche « objet métier » est réduite à une « Data Entity » sans la dimension « objet » : sans opération, ni cycle de vie.
Cette DataEntity est élaborée dans un 2nd temps après les processus métier. Contrairement à Praxème qui préconise d’élaborer des objets métiers (analyse de l’aspect sémantique, qui exprime la connaissance du métier, indépendamment de la façon de mener l’activité.) avant ou à minima avec les processus métier.
Je viens de suivre une formation TOGAF, et j’en ai profité pour apporter le support et les notes que j’ai prises lors d’une formation  Praxeme « Business Architecture & Transformation » suivie en début d’année.
Voici mes réflexions sur le mariage de ces deux framework d’entreprise :
Le méta-modèle de TOGAF (part. IV) peut converger avec Praxeme si l’on fait les modifications suivantes :
  • déplacer la « Data Entity » dans le domaine de la « Business Architecture » du « Metamodel Reference with Relationship »
  • renommer la « Data Entity » en « Business Object » et que l’on y prend en compte le cycle de vie et des opérations.
  • utiliser UML pour les objets métier et BPMN pour les processus métier
La part. III de l’ADM, nommée « guide lines & techniques », peut ensuite être complétée avec les guides de Praxeme : le guide de l’aspect intentionnel dans peut compléter la phase A, les guides des aspects sémantique (http://wiki.praxeme.org/uploads/Modus/PxPRD20Semantic_FR.pdf), pragmatique, géographique  peuvent compléter la phase B (analyse du métier) et l’aspect logique la phase C (analyse du système d’information) de l’ADM.
Je considère Praxeme comme un complément essentiel à TOGAF et il donc opportun que certaines entreprises choisissent de marier Praxeme et TOGAF.

CodevTT pour suivre l’avancement d’un projet

Louis travaille depuis 2010 sur un projet open source qui mérite d’être plus connu.

CodevTT  est un outil open source de gestion de projet, permettant un suivi détaillé de l’avancement des projets et des d’activités d’une équipe.

Il propose une interface web pour la saisie des comptes rendus d’activité, CodevTT collecte le consommé et le reste à faire sur les tâches. A partir de ces informations CodevTT génère rapports et indicateurs de productivité permettant de connaître en temps réel le niveau d’avancements des tâches et des demandes.


CodevTT est basé sur MantisBT, une solution open source de suivi d’anomalies écrite en PHP, dont il étend le périmètre fonctionnelle à la gestion du temps de travail.

Pour plus d’informations voir codevtt.org