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.

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 :
faire_acheter_louer

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.

build_run

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
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

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

Bilan de la journée OpenData de janvier 2013 à Aix en Provence

j’ai participé à la journée OpenData citoyen  et au Carrefour des possibles
qui se déroulait le 30 janvier à la Méjane à Aix.
Je n’ai pas pu suivre les conférences du matin, taf oblige, mais j’ai pu participer à un
atelier de l’après-midi avec des débats sur l’Open Data autour des questions sur
  • à quoi ça sert ?
  • qui organise l’OpenData ?
  • un intérêt pour l’économie ou uniquement pour la transparence des collectivités publiques ?
Si vous ne savez pas ce qu’est l’OpenData regarder cette prez, et aussi cet article.
Ensuite j’ai pu suivre une présentation du concept d’intelligence collective pour l’innovation dans les entreprises
avec la mise en place d’organisation hiérarchique très « plate » (peu de niveaux) et une rotation du leadership
un peu comme dans une équipe de foot qui joue : le leader est celui qui possède le ballon.
J’ai découvert les EPN (Espace Publique Numérique) auparavant des cybercafés/médiathèques
financées par les collectivités qui aujourd’hui évoluent vers d’autres activités geeks en fonction
des initiatives de leur animateurs.
À partir de 18h, il y a avait une autre manifestation : le carrefours des possibles
qui sélectionne et accompagne des porteurs de projet. 10 projets étaient présentés, j’ai surtout
retenus ceux-ci :
  • Draftquest : un site web qui aide des écrivains en herbe à écrire un roman en 90 jours (10 minutes par jours en s’appuyant sur des résultats de recherche sur la créativité par la contrainte. Le site sera n’est pas encore en ligne, un article en parle plus ici.
  • Hub-cité : un projet à Lomé (Togo) qui utilise les méthodes de travail et d’animation de l’open-source tels que les bar-camps (événement sur 1j à 3 semaines quelque part), fablab (lieu permanent dédié à une activité, ouvert au public) pour motiver les populations à démarrer eux-mêmes des projets, d’abord dans la construction de maison en terre, puis d’autres activités : la réparations d’appareils éléctriques ou de moteurs, de l’informatique, etc. Sur chaque thème des volontaires (étudiants le plus souvent) apportent leur savoir faire pour animer un bar-camp. Plus d’infos ici.
  • Kinoulink : un projet démarrer lors du dernier startup week-end de décembre dernier à Marseille : il s’agit d’envoyer des photos de la famille à un cadre photo numérique pré-configuré pour que Mamie puisse avoir régulièrement et simplement des photos de toutes la famille, avec un plus: Sur les photos on peu visualisé si quelqu’un est en ligne, alors Mamie touche un visage et ça appel la personne concernée (téléphone ou vidéo skype) si elle est dispo. Ils sont 7 sur le coup. Je leur ai présenté CatchU et m’on dit que par exemple la plateforme de collaboration les aurait biens aidés au départ pour s’organiser, et qu’ils auraient peut-être besoins de quelques dispositifs de l’association prochainement.

 

OpenStreetMap ou GoogleMaps pour mon service sur internet ?

De nombreux articles sur le web comparent GoogleMaps et OpenStreetMap, comme par exemple cet article d’Inaglobal, la présente note est focalisée sur les éléments de choix entre ces deux solutions dans le cadre de la réalisation d’un service sur internet nécessitant des données géographiques.

Pour choisir entre ces deux solutions, les critères suivants sont retenus :

  1. la simplicité d’utilisation de la solution par l’utilisateur final
  2. le coût de mise en place de la solution
  3. le coût d’exploitation de la solution
  4. la pérennité de la solution
  5. le degré de liberté d’utilisation de la solution

Le tableau suivant résume  les comparaisons faites dans cette note : OSM vs GoogleMaps pour développer des services sur internet :

  • un point est attribué pour la solution qui a le meilleur bilan pour chaque critère évalué
  • lorsque les solutions n’ont pas été départagées aucun point n’est donné
Critère OpenStreetMap GoogleMaps
la simplicité d’usage par l’utilisateur final 1 1
Coût de mise en place 1 0
Coût d’exploitation 1 0
Pérennité de la solution 0 0
Liberté d’utilisation de la solution 1 0
Total 4 1

Un créateur de service sur Internet qui souhaite rajouter des informations sur une carte et les exploiter dans une application devrait donc préférer OpenStreetMap.

Celui qui souhaite une autonomie complète devra installer son propre serveur de carte. OpenStreetMap s’inscrit dans la mouvance OpenData, ce sont d’abord les données brutes plus qu’un service qui sont fournies.

D’après des membres de la communauté OpenStreetMap, les principales raisons invoquées pour passer de GoogleMaps vers OpenStreetMap, sont :

  • la licence: OpenStreetMap permet de réutiliser librement (y compris pour l’usage commercial) ses données sur n’importe quel support, ce que ne permet pas Google, même à titre personnel.
  • l’aspect financier: si la mise en place d’un système de tuiles OpenStreetMap complet n’est pas gratuit, les coûts sont beaucoup plus maîtrisables qu’une licence Google
  • la possibilité de développer ses propres styles de rendu, ainsi que de faire des cartes thématiques
  • la réactivité des mises à jour, ce dernier point est à pondérer depuis le lancement de GoogleMaps Maker
  • l’indépendance vis-à-vis de Google

Présentation de l’OpenData

Vous ne connaissez pas l’Open Data ?

Littéralement une « donnée ouverte » est une information brute, publique, librement accessible.

La philosophie open data préconise une disponibilité des données gratuite, sans restriction de droits d’auteur, de brevets ou d’autres mécanismes de contrôle.

En France l’Open Data a débuté officiellement fin 2011 mais j’avais été assez déçu : incompatibilité des protocoles de communication, structure de données non compatibles, peu d’API, beaucoup de fichier non « parsable » (PDF), des sujets divers mélangés par fournisseur, données  non exhaustives, etc.

J’ai donc préféré ne pas en parler plutôt qu’être négatif. Depuis j’ai fait une petite présentation sur ce sujet avec un état des lieux pour la région PACA disponible ici.

voir aussi :

Quand choisir une solution SaaS dans une entreprise ?

J’en ai parlé lors de mon précédent billet, la commercialisation d’un logiciel en mode SaaS (pour Software as a Service) progresse fortement chez les éditeurs de logiciels car ce mode de vente apporte du chiffre d’affaire récurrent.

Mais quand utiliser ce type de service dans une entreprise ?

Pour une entreprise utilisatrice d’un logiciel sous la forme d’un service, le mode SaaS permet d’externaliser unepartie de l’activité informatique hors du système d’information, c’est utile par exemple pour une activité temporaire, ou pour minimiser l’investissement dans une nouvelle activité dont la rentabilité reste à vérifier.

Pour une comparaison des coûts il ne faut pas uniquement prendre en compte le coût de la licence du logicielen cas d’achat. La mise en production d’un logiciel en mode SaaS, comprenant l’installation et l’intégration sont à la charge de l’éditeur/hébergeur. L’infrastructure informatique de l’entreprise n’est pas impactée par le nouveau logiciel (pas de nouveau serveur, pas d’espace disque en plus). L’exploitation et la supervision du logiciel sont également à la charge
de l’éditeur/hébergeur.

Il restera les coûts d’intégration au système d’information de l’entreprise avec le logiciel loué et hébergé dans l’infrastructure informatique de l’éditeur/hébergeur (et les coûts de formation des utilisateurs). L’intégration au système d’information peut être couteuse et complexe s’il y a de nombreux flux d’échanges de données. Il peu y avoir aussi des risques de sécurité et de confidentialité des données du système d’information de l’entreprise.

Le mode SaaS est une solution d’externalisation de l’informatique qu’il faut réserver aux activités secondaires et non différenciatrice de l’offre des concurrents. Le coeur de métier et l’originalité de l’offre d’une entreprise ne doit pas dépendre d’un fournisseur et être pleinement maitrisée par l’entreprise. Où alors il s’agit d’un choix stratégique pleinement assumé par la direction générale de l’entreprise.