Le projet OCRopus qui a été récemment révélé au public illustre bien la méthode de gouvernance de l’innovation que Google a mise au point.

Comme son nom l’indique, ce projet concerne la lecture optique, une application stratégique pour Google qui a, on le sait, l’ambition de constituer de vastes bibliothèques numériques à partir de documents imprimés que l’on trouve dans les grandes bibliothèques. La digitalisation permet, en effet, d’intervenir sur le texte, de le sélectionner, de le copier, ce qui n’est pas possible avec les fichiers image classique. Mais ce n’est qu’une application parmi bien d’autres.

La lecture optique est utile:
- pour exploiter les documents .pdf comme des fichiers texte et automatiser la saisie de documents papiers (formulaires, courrier…). La poste est, d’ailleurs, l’une des premières utilisatrices de ces techniques et elle dispose, dans son groupe, d’une entreprise spécialisée qui a développé des technologies de reconnaissance de l’écriture cursive,
- pour lutter contre les spammers qui contournent les filtres en adressant à leurs victimes des fichiers images.

À plus long terme, on peut imaginer le développement d’outils qui permettraient à chacun d’utiliser les documents imprimés à notre disposition dans nos bibliothèques comme des documents électroniques. Il nous est tous arrivé de passer des heures à chercher dans un livre un passage qui nous avait frappé. La combinaison de la lecture optique et des outils de recherche pourrait résoudre élégamment ce problème1. En ce sens, le développement des techniques OCR est un complément naturel du développement des technologies du e-book et du e-paper.

Ces techniques sont du reste connues depuis longtemps. Les logiciels d’OCR existent depuis de nombreuses années. Ils ont fait ces dernières années de grands progrès, mais ils butent toujours sur plusieurs difficultés :
- le problème de la qualité, d’abord. Un OCR avec un taux de reconnaissance de 99%, ce qui serait excellent partout ailleurs, laisse dans le texte plusieurs fautes par page, fautes qu’un lecteur humain doit corriger. Les taux de réussite sont plutôt de l’ordre de 98% ;
- le problème du rendu de la mise en page, ensuite. Un document, c’est un texte, mais c’est aussi une forme avec des titres, des intertitres, des illustrations… qu’il faut savoir reconnaître si l’on veut produire un document lisible dans un autre format, sur un autre support, sur un PDA, un téléphone mobile…

OCCRopus illustre bien la méthode Google. Plutôt que de faire appel à un des produits disponibles sur marché, il reprend un moteur de lecture optique abandonné il y a une dizaine d’années par son créateur, HP, et libéré, mis en open source, il y a quelques mois : Tesseract. Ce choix n’est certainement pas innocent. Il libère l’entreprise de beaucoup de contraintes légales (négociation des licences…) et lui permet d’associer à son travail la communauté open source.

Ce choix met, par ailleurs, en évidence l’une des fonctions les moins connues de l’open source : sauver de la disparition ces millions de pages de code qui ont été écrites depuis 50 ans et qui, pour certaines, peuvent être réutilisées. Pourquoi réinventer ce qui existe déjà? L’open source est en ce sens une réponse à l’une des faiblesses de l’industrie informatique : comme il est difficile de protéger légalement le code, les entreprises ont gardé pour elles leurs sources, ce qui pouvait être un obstacle au développement technique que l’on ne rencontre pas là où les inventions sont publiées, que ce soit avec des brevets ou des publications scientifiques.

On lit, parfois, sur internet que c’est pour Google une manière de faire des économies. Ce n’est pas exact. Transformer un logiciel de ce type en solution open source a un coût que Google a supporté. En l’espèce, cette libération d’un logiciel ancien et depuis longtemps abandonné a une histoire. Des collaborateurs d’HP désolés de voir prendre la poussière ce produit qui avait gagné plusieurs concours se sont rapprochés de l’université de Las Vegas qui avait organisé dans les années 80 les concours de qualité de lecture optique pour “mettre au propre” leur logiciel, ce qu’elle a fait avec le soutien financier de Google. Ce n’est que lorsque ce logiciel a été débuggé qu’il a été libéré.
OCRopus associe à ce logiciels d’autres technologies, dont certaines développées par Google et d’autres développées par des chercheurs extérieurs à la disposition desquels il met ses bases de données considérables. La solution des problèmes de qualité signalés un peu plus haut vient probablement de l’analyse statistique. Lorsqu’il y a hésitation entre plusieurs interprétations d’une même lettre, l’analyse statistique doit permettre de proposer la solution la plus probable. La lecture de la mise en page, de la typographie s’appuie sur les travaux de Thomas Breuel et de son équipe.

Il y a donc croisement de technologie, mais celui-ci se fait sur le modèle du couteau suisse puisque Google explique clairement que Tesseract pourra, à l’avenir, être remplacé par d’autres moteurs de reconnaissance des caractères, notamment par celui qu’a développé en interne Google. “OCRopus is an OCR system that combines pluggable layout analysis, pluggable character recognition, and pluggable language modeling. Currently, OCRopus uses Tesseract as its only character recognition plugins, but in the future, there will be others (the code already exists, it just needs to be integrated) and you will be able to use OCRopus without Tesseract. OCRopus already has more powerful layout analysis than stand-alone Tesseract. Language modeling in OCRopus is currently similar to that in Tesseract, but it will be replaced with language modeling based on the OpenFST project as soon as that project makes its first official release.”

Cette structure en couteau suisse incite au respect des normes. Pour ne prendre que cet exemple, l’un des problèmes à résoudre était de choisir un langage de description des fichiers OCR qui présente simultanément les caractères ASCII issus de la digitalisation du texte et les marques de la mise en page et de la typographie (titres, chapitres…). Plutôt que d’inventer un nouveau langage, Google a choisi d’utiliser le plus connu et le plus utilisé de tous ces langages : html.

Google travaille sur ce projet en partenariat avec un centre de recherche allemand spécialis dans l’intelligence artificielle (DFKI) qui a développé des compétences dans le domaine de l’analyse de la mise en page des textes et dont le laboratoire spécialisé est dirigé par un chercheur, Thomas Breuel, qui connaît bien Tesseract pour avoir travaillé dessus comme consultant de l’administration américaine chargée du recensement mais qui est surtout connu pour avoir développé toute une série d’algorithmes sur la lecture de la mise en page.

La feuille de route des équipes chargées de développer ce projet a un spectre volontairement étroit, très ciblé, très serré puisque l’on passer de la versions alpha à la version 1.0 en 3 ans. Autant dire qu’elles doivent se concentrer sur l’essentiel et qu’elles peuvent, par ailleurs, rester de petite taille. Le projet n’occupera, pour la partie réalisée en Allemagne, que trois chercheurs, étudiants en PHD ou postdoc. Tout le reste est confié à la communauté des développeurs open source qui ont accès aux sources du logiciel. Ce moteur est développé sous Linux. Les développeurs peuvent, s’ils le souhaitent, créer des versions pour d’autres systèmes d’exploitation, pour Windows ou OS X (Apple). Ce moteur ne traite que l’anglais, la communauté open source est invitée à développer des modules pour les autres langues (langues avec des signes diacritiques inexistants en anglais, comme les lettres accentuées, règles typographiques différentes…). La communauté est également invitée à développer des interfaces utilisateur, des systèmes d’apprentissage, en un mot tous les modules qui le rendront facilement utilisable.

On voit donc bien se construire un mode de gouvernance de l’innovation très particulier. L’entreprise définit un projet très étroit, qu’elle développe en association avec :
- des partenaires universitaires choisis pour leurs compétences dans le domaine. C’est moins l’université qui a été choisie que le patron de son laboratoire de recherche, Thomas Breuel, qui a une longue carrière dans le domaine de la reconnaissance des formes, qui a travaillé au PARC, chez IBM, dans un laboratoire d’intelligence artificiel suisse, à Martigny, qui connaît déjà Tesseract, qui a beaucoup publié sur le sujet et qui est donc très connu et qui, du fait même de cette réputation, attire auprès les meilleurs étudiants et chercheurs.
- la communauté à laquelle est confié le soin de développer tout ce qui entoure son projet initial. Celle-ci informe immédiatement ses membres des possibilités qui sont ainsi ouvertes. Pourquoi la communauté le ferait-elle? Mais parce qu’elle y a intérêt. Surtout si elle a l’ambition de développer des applications autour du produit central. Or, on commence à voir émerger un marché autour de la reconnaissance optique. Pour ne prendre que cet exemple, il existe une société, ScanR, qui scanne et lit les documents que l’on a photographiés avec son téléphone mobile et qu’on lui adresse (il peut s’agir de pages de textes, mais également d’écrans, de tableaux…).

Le premier avantage est la simplicité : on peut rester focalisé sur l’objectif central, la qualité de la lecture. Le projet est à taille humaine, il reste centré sur la dimension technologique. On laisse au marché le soin de définir les applications, les outils les plus utiles. Ce n’est plus une direction marketing qui décrit le produit mais les utilisateurs qui développent et qui sélectionnent les applications qui leur paraissent le plus intéressantes.

Le second avantage est l’utilisation des produits existants et le renforcement des normes du marché.

Le troisième avantage est la facilité du suivi du projet : l’état d’avancement peut être facilement contrôlé.

Un quatrième avantage est la flexibilité : on insiste sur la réutilisation de technologies existantes mais que l’on se donne en même temps la possibilité, grâce à la structure en couteau suisse, d’intégrer si nécessaire, des technologies plus performantes. On peut donc faire évoluer le produit final relativement rapidement. On lui donne une certaine flexibilité. On introduit la possibilité du changement dans la conception même du produit.

Documents
- site du langage hocr : https://misc.iupr.org/docs/doku.php?id=pub:hocr:ocr-in-html
- site d’OCRopus : http://code.google.com/p/ocropus/
- DFKI : http://www.dfki.de/web