parallèle Sudoku et résolution de problèmes

Peut-on faire un parallèle entre les jeux comme le sudoku et les problèmes de la vie courante ?

Liste d’affirmations :

1. La difficulté d’un problème est liée aux informations en entrée pour l’analyser
   Sudoku : Plus le niveau du sudoku est élevé, moins de chiffres sont présents sur la grille
   c’est vrai et faux, la position ou la valeur des chiffres, influence aussi sur la difficulté.
2. Plus un problème à de solutions, moins il est difficile à résoudre.
   Sudoku : Plus le niveau augmente, plus en général, il y a de solutions. du coup, un doute persiste, car à priori on pense qu’il n’y a qu’une solution
3. Il y a des problèmes sans solution
   Sudoku : sauf erreur au moment de la conception, il y a toujours au moins une solution
4. La solution peut-être trouvé par hasard
   Sudoku : Au regard des combinaisons, sans raisonnement logique, il y a peu de chance de trouver la solution (du moins au début).
   En fait c’est vrai et faux, car si deux solutions sont possible, à un moment donné il faut prendre au hasard, un des chiffres possible (restant) pour s’orienter vers une des solutions

Maintenant, prenons comme hypothèse que les problèmes de la vie, professionnelle ou personnelle, sont comme des Sudoku, que peut-on en déduire ?

1. La difficulté d’un problème n’est pas toujours liée au peu d’information à notre disposition, mais à la variété de celle-ci. Il faut donc augmenter le nombre de ces sources, les angles d’attaques et les points de vus
2. Il est plus simple de résoudre un problème avec une solution unique, qu’un problème avec plusieurs solutions. Car pour faire le choix d’une des solutions, il faut vérifier qu’aucune autre alternative est possible et qu’aucune erreur d’analyse, de raisonnement nous oriente vers une mauvaise solution.
3. « Un problème sans solution est un problème mal posé. » Albert Einstein.
   Ce grand homme considère donc que tout problème a bien une solution =D
4. Sauf problème simple, le hasard ne permet pas de résoudre un problème complexe. Mais il faut à un moment accepter le fait que l’on a :
   1. plusieurs solutions qui existent et qu’elles sont toutes acceptables
   2. faire un choix, ne veut pas dire pour autant que la solution prise est le fruit du hasard, mais qu’après avoir éliminé différentes alternatives, il peut en rester plusieurs, toutes acceptables
   3. à se faire confiance

Ce raisonnement est simpliste, mais il doit au moins permettre de s’interroger sur le sujet.

En fait, il est notamment faux pour tous les problèmes où le résultat attendu peut-être différent de la problématique initiale, je pense notamment à un raisonnement agile. Il est faux aussi dans bien d’autres cas que je vous laisse le soin de découvrir…

Je finirais cette réflexion par une nouvelle citation d’Albert Einstein  : « En plein cœur de toute difficulté se cache une possibilité ».

 

C’est quoi un bon MOOC ?

Mooc pour massive open online course, en français Formation en ligne Ouverte à tous (FLOT)  ou Cours en ligne, ouvert et massif  (CLOM).

Voici ma vision du MOOC idéal, après en avoir suivi plusieurs jusqu’au bout, de différents organismes.

Pour avoir du plaisir à faire un MOOC et avoir envie d’aller jusqu’au bout, il faut :

1. Une notion de récompense, certificat ou équivalent
2. Un livrable en fin de chaque semaine (QUIZZ et/ou Exercice),  avec la possibilité de poursuivre et d’avoir son certificat, si les devoirs n’ont pas été rendus à temps (dans la limite du raisonnable).
3. Une durée courte, quelques semaines
4. Un temps de travail hebdomadaire de quelques heures, en visionnage/lecture et en travail à réaliser.
5. Un plate forme simple à utiliser
6. Des vidéos avec les textes de ces vidéos, la possibilité de télécharger les vidéos, pour une lecture en locale
7. Une progression croissante dans la difficulté, on doit être dans le succès et finalement ne pas sentir la difficulté augmenter
8. Une notion collaborative, comme corriger les « exercices » des autres stagiaires avec une notation guidée, indiscutable et juste avec la correction type du ou des exercice(s) . Mais il faut aller plus loin encore, peut-être des travaux à faire à plusieurs..
9. Un esprit de communauté, d’équipe, même si on est seul devant l’ordinateur, il ne faut pas rester seul dans le MOOC.
10. Le moyen d’aller plus loin (vidéo d’expert, URL etc..), si on veut passer 35h/semaine sur le MOOC ce doit être possible..
11. Un coté décontracté et sérieux à la fois, dans les vidéos, les textes..
12. Une pédagogie forte, qui s’appuie sur des exemples simples et compréhensibles par tous.
13. Une disponibilité de la plateforme 24h/24h

Voici ma vision du MOOC idéal.

des liens sur le sujet :

1. http://parlonsmooc.fr/QuEstCeQuiFaitUnBonMooc.htm
2. https://www.fun-mooc.fr/
3. https://unow-mooc.org/
4. http://openclassrooms.com/
5. http://mooc-francophone.com/
6. http://www.firstbusinessmooc.org/
7. http://www.france-universite-numerique.fr/
8. La révolution MOOC, Matthieu CISEL

Liens vers mes badges « gagnés » sur unow : badge.unow.fr

Automatisation de lecture des formulaires de cases à cocher

Nous venons de développer un outil de lecture automatique de cases à cocher.

Après un état de l’art sur le sujet, on s’aperçoit que ce sujet n’est plus d’actualité, plus de recherches scientifiques depuis de nombreuses années, grave erreur 😉

Il est vrai que le formulaire électronique est en vogue, mais il y encore des contextes où l’usage de celui-ci, n’est pas possible.

En tant que prestataire de service en dématérialisation, nous avons la chance d’avoir de la volumétrie.

Voici quelques exemples de cases cocher :

exemple de cases à cocher

à priori on ne voit pas la difficulté pour détecter que la case est cochée ou non. En analysant simplement le nombre de pixels noir au centre des cases on détecte facilement si la case est cochée ou non.

Voici quelques exemples où l’on commence à comprendre les difficultés que l’on rencontre :

coche entre deux cases

Certains de nos clients nous demande de prendre en compte ce type de coche, en prenant l’option la plus négative, ici « Peu Satisfait », pour la deuxième question.

coche verticale au lieu d’une croix

Un dernier exemple, mais il y en a des dizaines d’autres, pour lequel la règle d’analyse citée ci-dessus ne fonctionne pas :

la personne au lieu de cocher les cases a entouré celles-ci

Une fois de plus, un sujet qui semble simple, cache de l’intérêt pour la recherche et pour un prestataire externe.

Une petite dernière…

Une ambiguïté de compréhension possible

PS : pensez aux personnes qui font des ratures …

 

Le PDF/A-1 -2 – 3 -x

La norme ISO PDF/A

L’objet de cet article n’est pas de décrire le format PDF/A, avec ces avantages et ces inconvénients, voir pour cela :

1. http://fr.wikipedia.org/wiki/PDF/A-1
2. http://www.pdfa.org/2009/09/pdfa-une-nouvelle-norme-pour-larchivage-a-long-terme/?lang=fr

L’objet de cet article est de faire un retour sur son usage, afin de répondre aux questions suivantes :

1. Tous les logiciels qui indiquent faire de PDF/A suivent t’ils la norme ?
2. Peut-on faire du PDF Optimisé avec du PDF/A
3. Relation signature électronique et PDF/A
4. Taille des fichiers PDF/A
5. Modification d’un PDF/A
6. Tous les PDF peuvent ils devenir des fichier PDF/A

Tous les logiciels qui indiquent faire de PDF/A suivent t’ils la norme ?

NON. C’est terrible, mais des logiciels permettent de valider les fichiers PDF/A et surprise de nombreux PDF dit PDF/A ne suivent pas la norme. ;-(

Peut-on faire du PDF Optimisé avec du PDF/A

OUI et NON. La norme PDF/A-1 trop ancienne n’autorise pas les PDF Optimisés. A partir de la La norme PDF/A-2, on peut intégrer des formats d’images optimisées pour les images couleurs et niveaux de gris. On peut aussi compresser sans perte d’information les images N&B, gain environ 50% par rapport aux images tiff group IV. 😉

Relation signature électronique et PDF/A

OUI. On peut signer un fichier PDF au format PDF/A sans que celui-ci perde son statu PDF/A

Les fichiers PDF/A sont plus gros

OUI. car on cherche à tout embarquer, notamment les polices de caractères. La taille des fichiers PDF/A est donc plus importante que les fichiers PDF normaux.

Modification d’un PDF/A

NON. La modification d’un fichier PDF suivant la norme PDF/A, perd son statu PDF/A, il faut alors relancer la conversion en PDF/A

Tous les fichiers PDF peuvent-ils passer en PDF/A ?

NON. Si le fichier a mal été crée au départ, par exemple création à partir d’un logiciel, comme Word de Microsoft, et le document d’origine comporte des polices de caractères spécifiques installés sur le poste. Dans ce cas, au moment de la demande de passage en PDF/A sur un autre poste de ce PDF, le système va chercher les polices de caractères, ne les trouvant pas il refusera la conversion.

Voilà une petite liste de questions/réponses sur le PDF/A

 

 

Pensée Design et méthode Agile

Inscrit sur un Mooc sur la « pensée Design« , j’ai découvert des liens forts avec les méthodes agiles. L’objet de cet article est de voir les similitudes entre ces deux mondes.

En premier une petite définition du « Design ».

Le terme design, vient du verbe anglais « to design », ce n’est donc pas un adjectif mais un verbe. Dire « cet objet est design », ne veut donc rien dire. C’est comme si on disait il a été conçut… 😉 Si je le vois c’est que probablement il l’a été créé …

La pensée design est une méthode

Cette méthode est en 5 étapes :

– L’étape 1 l’empathie consiste à favoriser une démarche permettant de se mettre à la place du consommateur final et comprendre ses besoins.
– L’étape 2 définir le problème à sa source, par notamment la technique des « 5 pourquoi »
– L’étape 3 l’idéation (Processus de création d’une idée) , l’objectif de cette phase étant de générer un maximum d’idées pour solutionner notre problématique initiale , On pratiquera alors le brainstorming
– L’étape 4 le prototypage, c’est à dire le travail consistant à donner une forme physique à notre idée retenue.
– l’étape 5 une phase de test celle consistant à recueillir un maximum de feedbacks par l’utilisateur final.

Une boucle naturelle existe alors entre les étapes 4 et 5.

Maintenant petit parallèle entre les deux méthodes

1. Le client est au centre des deux méthodes : Dans les méthodes agiles, le client est au cœur du développement, il est même idéalement au milieu de l’équipe de développement. Dans la pensée design, dès l’étape 1, il est sollicité, à s’exprimer, à décrire son problème, il va tester et commenter le prototype etc…
2. La notion de prototype : En Pensée design, on concrétise ses idées par des prototypes que l’on présente au client, idéalement pour qu’ils puissent les tester. En méthode agile, on fait des itérations rapides, dans le but de livrer, et de permettre au client d’utiliser son produit dès que possible. Dans les deux méthodes, le client va effectuer des feedbacks, de commentaires, qui vont modifier le produit final.
3. La notion de test et d’itération : En méthode agile on développe par tranche de 10 à 15 jours (en faisant le cycle complet de développement, jusqu’à la livraison), tout cela en développement par les tests : test de non régression, test fonctionnel, test unitaire etc.. En pensée design, le processus n’est pas aussi poussé, mais il y a biens des tests pratiqués sur les prototypes qui vont au fil des itérations se rapprocher du produit final.

Ce parallèle effectué entre ces deux méthodes, peut se faire aussi avec d’autres méthodes.

Si je prends par exemple la phrase de la méthode de management Kaizen « Fais-le mieux, rends-le meilleur, améliore-le même s’il n’est pas cassé, parce que si nous ne le faisons pas, nous ne pouvons pas concurrencer ceux qui le font. »

Reprenons dans les méthodes agiles les concepts de « refactoring » &  « faire le plus simple », on est bien dans des méthodes très similaires.

Ma conclusion, si nous voulons progresser en méthode agile, soyons curieux, et regardons les autres méthodes et techniques qui existent.

quelques liens :

1. mooc pensée design
2. Wikipédia pensée design
3. Wikipédia Kaisen
4. Wikipedia 5 pourquoi

à bientôt..

SDNRI 19-21 mars 2014 (CIFED+CORIA), mon résumé

Semaine du Document Numérique et de la Recherche d’Information 2014 (SDNRI)

Présent à cette conférence qui regroupe deux mondes de la recherche : la recherche d’informations (CORIA) et l’analyse d’image de document (CIFED), je vous propose mon résumé en tant qu’industriel, plus orienté CIFED, il fallait faire des choix ;-).

L’objet de ces colloques est la présentation de ce qui se fait actuellement dans les laboratoires, pour l’analyse de document : factures, documents techniques, courrier entrant, etc.. On n’est donc pas sur la vidéo, la 3D, la réalité virtuelle.. c’est vraiment la partie dématérialisation et indexation des documents.

95% de chercheurs et 5% d’industriels (3 sociétés de mémoire… mais on était plutôt silencieux).

Les recherches actuelles portent sur :

• Reconnaissance manuscrite, avec notamment l’intervention d’ Alex Graves, par une technique Biderictionnal RNNs
• Améliorer la classification de documents par combinaison de descripteurs visuels et textuels (Fait par mon collègue Olivier AUGEREAU)
• La différenciation texte manuscrit et texte typographié, afin notamment d’appliquer un OCR ou ICR en fonction de ce qui a été trouvé
• La détection d’une première page de document dans un flux documentaire
• La recherche de formule chimique dans un document
• Classification de document par l’analyse de logo.
• Classification mono-classe de document industriel
• Génération de données semi-synthétiques pour l’amélioration des techniques d’apprentissage.
• Analyse de document par smartphone
• Analyse de la couleur sur des formulaires

Les recherches en cours sont biens dans les problématiques industrielles, en interne nous travaillons sur une grande partie de ces sujets à notre niveau bien sûr.

Comme certaines conférences étaient communes avec la partie CORIA, j’ai pu notamment assister à la présentation Iadh Ounis  de l’université de Glasgow, qui a présenté un système de détection d’événement par l’analyse quasi temps réel des tweets dans le monde. Des problématiques informatiques impressionnantes au regard des volumétries, plus de 100 000 tweets analysés par seconde. L’objectif étant d’informer la police, les journalistes, etc… d’événements qui se produisent. L’idée originale est de croiser dans la foulée, les recherches effectuée sur Wikipedia sur ces mêmes sujets, 2 heures après les tweets.

pour plus d’information sur ce colloque http://sdnri2014.loria.fr/ 

Signature électronique sur une feuille de papier ?

Le document Hybride

Dans le cadre de la dématérisalisation de documents, des questions concernent souvent la notion de copie, de preuve, de valeur probatoire, de notion d’intégrité du résultat de la numérisation etc..mais quand est-il de l' »original » numérisé.

Qu’est ce qui prouve aujourd’hui qu’une facture papier d’Orange provient vraiment d’Orange et que les données qu’elle contient n’ont pas été modifiées ?

Plusieurs problématiques :

• Les factures d’Orange sont au format électronique, la version papier n’est finalement plus l’original, mais une impression de l’original électronique, donc une copie.
• L’impression est réalisée par une personne qui peut avoir modifiée le contenu de la version électronique, avant l’impression, même si elle est au format PDF, par exemple pour indiquer une autre adresse, une autre identité.

Quelle fût ma surprise il y a quelques années, lorsque j’ai croisé la FNTC (Fédération des tiers de confiance), sur un salon, qui ont travaillé sur le document hybride. On m’explique alors que l’on peut ajouter une signature électronique horodatée sur un document papier !!.

Le meilleur exemple d’utilisation est le billet de train, imprimé sur Internet, avec son code 2D, visible en haut à droite de la feuille A4, Le contrôleur, douche celui-ci est croise les informations lues avec le texte écrit sur le billet. Les modifications du billet seraient alors détectées. Le système utilise une clef privée pour la constitution de ce code, une clef public pour la lire.

Il y a quatre intérêts à cette technique :

• La réduction de la fraude.
• La possibilité de relire certain texte sur la version papier sans faire de l’OCR (Reconnaissance Optique de Caractères) et donc sans risque d’erreur
• la possibilité d’utiliser cette technique avec un équipement d’impression standard (pas d’utilisation d’hologrammes ou d’encre magnétique).
• La possibilité de relire facilement l’information

Liens sur le sujet :

• Une superbe publication a été écrite sur le sujet, en libre accès, par la FNTC (Fédération des Tiers de confiance) téléchargeable ici :  http://www.fntc.org/fr/publications/func-startdown/256/
• http://cerig.efpg.inpg.fr/memoire/2012/codes-2D.htm

Deux techniques supplémentaires existent :

• Cacher sur la version papier, visible par un scanner mais pas par un humain. Le fraudeur risque donc de se faire avoir …
• Augmenter la densité des informations dans le code, qui va du coup nécessiter une imprimante et un scanner qui sont un peu plus évolués. On peut alors encoder plus que le texte, par exemple de l’en-tête et le pied de page d’une facture, mais tout le contenu textuel de la facture.

 

Retour d’expérience écran tactile grand format

Dans le cadre de l’amélioration de nos outils de production, nous avons développé une interface de classification de documents, sur un écran tactile 23″.

Nous avons développé en interface tactile, car l’utilisateur classifie des images numérisées en recto-Verso et on souhaitait lui présenter une interface et une utilisation proche de celle qu’il avait avant avec les originaux papiers.

Dans notre contexte, l’utilisateur est assis devant cet écran qui est dans la position habituelle d’un écran d’ordinateur, mais plus proche et plus penché.

L’objet de cet article est le retour de cette expérience.

Le développement a été fait en utilisant WPF en C# avec Visual Studio 2012, aucun soucis à ce stade.

Les retours au niveau interface, par rapport à une interface souris, sont les suivants :

– les zones sensibles doivent être plus grandes,
– les zones les plus utilisées doivent être en bas de l’écran,
– les barres de défilement doivent être adaptées (plus large)

Les points de vigilance sont :

– l’écran doit être penché, il doit être assez proche de l’utilisateur
– l’écran ne doit pas être brillant car son inclinaison peut être la cause de reflet (lumière d’en haut)
– prendre en compte la fatigue des membres plus sollicités que lors de l’utilisation de la souris
– la nécessité de saisir de temps à autre, n’est pas pratique sur ce type d’écran. Il n’y a pas la  possibilité de faire apparaître le clavier à l’endroit de son choix. Le fait d’utiliser un vrai clavier éloigne de l’écran l’opérateur, ce qui n’est pas bon dans ce contexte.

Au final, après plusieurs mois d’utilisation, on s’aperçoit, un abandon pour certains opérateurs et un retour à la souris, d’autres utilisent un mixte souris/écran tactile. aucun n’est au final resté au tactile pure.

Attention : une simple mouche sur l’écran peut être prise en compte par le système, voir une simple poussière … 😉

5 ans de développement en méthode Agile, retour d’expérience

Pourquoi cet article ?

Tout ce que j’ai lu et appris sur le sujet concerne des équipes qui sont sur un seul projet, ce qui n’est pas notre cas. Il m’a semblait intéressant de partager cette expérience très différente du mono-projet.

En plus de lire sur le sujet, nous sommes allés à plusieurs reprises aux conférences proposées dans le cadre de l’Agile tour : http://at2013.agiletour.org/fr/at2013_bordeaux.html

Cela fait environ 5 ans que l’on travaille en méthode agile, mélange d’EXtrême Programming (XP), scrum et sauce maison.

Voici le contexte :

• Service informatique dans une société qui n’est pas une SSII, l’équipe est composé de 15 développeurs
• il y a en parallèle une dizaine de projets, avec des équipes de 3 développeurs, jusqu’à 1/4 de développeur
• Les développements concernent en grande partie les besoins internes à l’entreprise
• Développement en C#, l’équipe de développement à une moyenne d’age de 27 ans (je ne me compte pas dedans .. heureusement pour la moyenne…)

Nous avons au fil du temps testé différents aspects :

• Le management visuel
• les planning poker
• les post-it
• le travail en binôme
• les tests unitaires
• les tests fonctionnels
• les points quotidiens avec le client
• Le refactoring de code
• etc..

Les points positifs qui dans le temps tiennent :

• le travail en binôme, qui apporte un plus réel au niveau polyvalence, formation, arrivé de nouveaux développeurs
• le planning poker, qui en comparant l’estimation et le réel donne d’excellent résultat. Des alertes naturelles sont faites, afin d’éviter de refaire un code déjà réalisé sur un autre projet
• les test fonctionnels, mais qui restent difficiles à automatiser, au regard de nos applications (clients lourds et clients légers, contexte parfois difficile à reproduire etc…)
• La notion de fiche scénario courte, qui donne un sentiment, pour le développeur d’une bonne journée. On essai de faire des fiches d’une 1/2 journée et pas de 5 jours.
• l’effet tunnel qui n’existe plus

Les points négatifs :

• l’utilisation des post-it, qui n’a pas de sens en multi-projet, qui tombent, qui sont trop petits pour tout écrire dedans etc..
• le travail en binôme, si décalage important de niveaux ou dans un contexte de développement simple
• la notion d’itération qui ne peut être unique si multiples projets
• l’ambiance de l’équipe par des pastilles de couleurs, n’a pas marché, même si cela donnait une bonne vision par jour et dans le mois du ressenti de l’équipe.
• Les points quotidiens avec le client, sont difficiles à faire, en raison notamment de la charge de nos clients internes. Ceux qui peuvent jouer le jeu ont de meilleurs développements, c’est indéniable.

Même si on peut voir que tout n’est pas utilisé les grands concepts sont compris et appliqués, par exemple :

• En parallèle nous faisons les tests, les développements et le manuel de référence. Il y a donc 3 lectures différentes de ce qui doit être réalisé.
• la part de test a explosé et à permis d’avoir des développements plus fiables
• On ne développe plus que ce qui est demandé par le client
• On ne pose plus de questions au client du type « est que cela pourrait vous intéresser ? »
• Le client est plus en avant qu’avant.. ce qui est l’essentiel, pas de surprise pour lui ..

En espérant que cet article aidera des équipes de développement comme la notre…

Développer dans Kofax Express

La dématérialisation, ne nécessite pas toujours le numérisation, mais si tel est le cas, un logiciel de scannérisation est souvent nécessaire.

Nous avons expérimenté le logiciel Kofax Express.

Pourquoi ce choix ? : la possibilité de développer, on peut ainsi l’adapter au besoin. En tant que prestataire de service, c’est essentiel de pouvoir s’adapter aux demandes des clients.

Le produit permet l’ajout de code lors de la phase d’indexation, on doit développer en VB.NET. Le logiciel propose en standard (sans développement) des contrôles de type expressions régulières ou contrôle par croisement avec une base de données (très simple d’utilisation). Il existe néanmoins des limites, par exemple, on ne peut pas sans programmation, faire un contrôle avec une notion de OU. La saisie doit répondre à ce format ou ce format, les deux étant très différents. Par contre, Il n’est pas possible par programmation d’avoir le même comportement de gestion d’erreur que le produit.

Le deuxième endroit où l’on peut développer, est au moment de l’exportation. On appel cela un connecteur d’export. On peut toujours développer en VB.Net, mais aussi C# etc.. Manifestement, c’est à ce niveau que Kofax souhaite que l’on développe. On peut alors sous Visual Studio, développer ce que l’on veut.. très grande liberté de langage, de possibilité.

Nous avons par exemple développé :

1. une génération d’un CSV d’indexation à notre sauce, en plus de l’export d’images
   
2. l’affichage d’écran de contrôle personnalisé
   
3. la génération d’arborescence de fichiers, en fonction de valeur d’index
   
4. des nommages de fichiers exotiques
   
5. etc..
   

à priori pas de limite : envoi FTP, mail, etc…