home-featured

Je viens de recevoir aujourd’hui un courriel des plus intéressant de WPML après qu’ils m’aient aidé à résoudre un problème avec mon site web.

WPML et M2i3 ont une philosophie similaire : nous ne voulons pas avoir accès à quelque chose plus longtemps que nécessaire.

Pourtant, très souvent, les clients me donnent leur mot de passe pour que nous puissions gérer leurs comptes ou les aider à résoudre des problèmes.

Dans le meilleur des mondes, je devrais avoir un compte qui me soit propre. Sinon, je leur dis de le modifier avant de nous le donner (car la plupart des gens réutilisent les mots de passe) et de le modifier à nouveau après que nous ayons terminé.

Dois-je aller vérifier s’ils ont vraiment supprimé les comptes ou changé les mots de passe ?

Non

Ce serait inapproprié et, dans une certaine mesure, une tentative de violation de leur infrastructure. Quoi qu’il en soit, je saurai s’ils l’ont modifié la prochaine fois qu’ils demanderont de l’aide.

Je vous pose donc la question suivante : « Dans quelle mesure faites-vous attention à supprimer les comptes et à changer les mots de passe que vous avez donnés aux fournisseurs qui vous assistent ? »

C’est très important de nos jours, car si elles sont violées, c’est votre propre infrastructure qui est exposée. Les données de vos clients sont potentiellement exposées.

Et, si vous êtes au Québec, la loi 25 du Québec vous obligera à divulguer l’événement qui aura un impact sur votre crédibilité. Si vous ne le faites pas, vous vous exposez à de lourdes amendes (comme si la perte de crédibilité ne suffisait pas).

Comment fermer ces portes?

Il y a plusieurs choses que vous pouvez faire pour améliorer votre position en matière de sécurité :

1. changez votre mot de passe avant et après l’avoir donné à un fournisseur (il est en fait conseillé de changer régulièrement de mot de passe)
2. créez des comptes spécifiques pour vos fournisseurs lorsque c’est possible, indiquez clairement qu’il s’agit de fournisseurs (utilisez le nom de leur organisation plutôt que le nom de la personne qui vous aide).
3. tenez un registre des personnes à qui vous avez donné l’accès, jusqu’à ce qu’elles en aient besoin, et supprimez ces comptes lorsqu’ils ne sont plus nécessaires
4. examiner régulièrement qui a accès à quel système. Supprimez toute personne qui ne devrait plus avoir accès au site.

Grâce à ces petites mesures, votre infrastructure et vos données seront beaucoup plus sûres.

—
Jean-Marc

Il y a bien des questions qu’un enfant peut demander mais aucune aussi puissante que la questions « pourquoi ». Vous connaissez cette phase où les enfants qui nous entoure vont demander « pourquoi » sur à peu près tous les sujets possibles et imaginables (et même certains qu’on préférerait ne pas imaginer). Cette question est tellement importante que Toyota l’a même intégré à son propre processus de troubleshooting (« élimination de problème ») sous la forme des cinq pourquoi (« 5 whys »).
La méthode fonctionne ailleurs qu’en résolution de problème. C’est en fait un de mes outils préférés en analyse puisqu’il nous permet de creuser une demande, une motivation, un problème, la raison derrière toute demande (enfin pour autant que les deux parties soient honnêtes et connaissantes). Je ne vous cacherai pas que se faire demander à mainte reprise « mais, pourquoi » peut être très frustrant (n’importe quel parent peut vous le confirmer). Ceci-dit, le jeu en vaut la chandelle, puisqu’au final vous obtiendriez une situation claire et surtout libre de toutes idées préconçues.
Bien sûr il faut un peu de bonne volonté pour y arriver.
Prenons un exemple hypothétique:

• Client: « j’aimerais que le fond de ma page soit rose avec du bling bling qui bouge »
• Designer: « pourquoi? »
• Client: « parce que rose c’est la couleur de ma compagnie et que je veux du rose sur le site web »
• Designer: « d’accord et le bling bling? »
• Client: « parce que juste rose ça va faire trop simple et que le fond d’une page c’est comme un mur et que ça doit être peinturé pour être agréable »
• Designer: « comme un mur? pourquoi pensez-vous cela? »
• Client: « je l’ai lu quelque part »
• Designer: « et le rose et le bling bling, ils viennent d’où? »
• Client: « parce que je vends des accessoires de mode pour de jeunes filles et que le rose c’est féminin et jeune. tout comme le bling bling »

La quantité d’information obtenu dans une telle conversation est énorme. Le potentiel d’éducation aussi. Le designer peut maintenant éduquer sur l’importance de ne pas distraire le visiteur sur les produits vendus et la transaction d’achat. Il a aussi obtenu une montagne d’information sur l’âge, le style de la clientèle visée. Et, au final, que le fond de la page devienne rose pétant (ou pas), comme designer vous avez maintenant en main beaucoup d’information pour intégrer et mieux rejoindre la clientèle que si vous vous étiez arrêté à la première question.
Comme client, être la cible de ces questions peut sembler désagréable et dans le fond ça l’est puisqu’on revisite alors des informations acquises depuis longtemps. Cependant il faut garder en tête que le designer et concepteur de votre site web ne connaît pas tout de votre entreprise et de votre mission. Il faut bien l’éduquer un peu sur ce qui vous a amené à choisir telle couleur. Au final vous risquez même d’apprendre ou même de redécouvrir quelque chose d’important sur votre entreprise.
Comme mon père disait: « il n’y a pas de questions stupides ». Bon, dans les faits il y en a, mais vous comprenez mon point.
Tous les aspects d’un design et d’un site web doivent être analysé et creusé à leur motivation de base. Chaque requête ausculté sur tous ses angles. C’est la seule façon de savoir si on tiens quelque chose de solide ou simplement un « on va mettre un chaton, c’est beau un chaton, j’adore les chatons ».
Il y a un risque à suivre la logique et à trop creuser un design. Premièrement, parce qu’un design fait souvent appel à l’émotion et que les gens vont réagir différemment aux couleurs et polices. Il y a aussi la problématique des connaissances. La personne qui travaille avec vous ne connaît peut être pas les raisons profondes. En fait, des fois, il n’y a tout simplement pas de raisons ou cette dernière est tellement ridicule qu’on va préférer la garder secrète. L’honnêteté est primordiale dans un tel processus et répondre: « je ne sais pas » est tout à fais acceptable.
Ceci-dit, il y a d’autres méthodes pour obtenir un design solide. L’expérimentation et les tests A/B font partie des outils permettant au designer de créer une expérience utilisateur qui va supporter les objectifs d’affaires. Et n’oublions pas qu’il n’est pas le seul à pouvoir demander « pourquoi ». En tant que client vous pouvez et devriez questionner les choix de votre designer.
Alors, pourquoi est-ce que le ciel est bleu? Une question toute anodine, entendue des milliers de fois. Et pourtant, l’outil de design et de conception le plus important que l’on possède.
—
Jean-Marc

Tags: mouvement agile, manifesto, philosophie

Notre site comporte une version française du manifeste pour le développement de logiciel Agile et après un mois dans la nouvelle année je crois qu’il est important de le remettre à l’ordre du jour. Pas parce que je doute de la qualité du travail de mes collègues qui travaillent avec SCRUM mais bien parce q’un retour au sources s’impose.

Les signataires du manifeste ont réfléchis longtemps aux valeurs du manifeste pour rendre le développement logiciel plus viable, plus durable et plus humain. Personnellement je vois dans ce manifeste le rappel qu’en tant que profession nous en sommes encore au stade du maître-compagnon-apprenti. Nous avons formalisé et codifié beaucoup d’aspects de notre métier mais il y a tellement encore à découvrir sur les dynamiques du développement logiciel qu’il me semble encore trop tôt pour adopter un comportement et des méthodologies tirées de l’ingénierie.

Et même si nous en étions arrivés à ce stade le manifeste redonne une dimension humaine nécessaire à notre travail. Il tient compte des incessants changements propre aux processus d’apprentissages (même en 2013).

Je réinscrit donc la version officiel (en français) du manifeste comme un testament à ses principes:
Les individus et leurs interactions plus que les processus et les outils
Des logiciels opérationnels plus qu’une documentation exhaustive
La collaboration avec les clients plus que la négociation contractuelle
L’adaptation au changement plus que le suivi d’un plan
(source: http://agilemanifesto.org/iso/fr/)

—
Jean-Marc