kadata - le blog

Le développement des TIC a fait explosé le volume de données produites dans le monde. Marc Andreessen dans un article déjà cité ici intitulé "Software is eating the world" rendait compte du premier mouvement. Certains on rapidement vu que ce développement du tout logiciel cachait une deuxième révolution, celle de la donnée : “data is eating software”. Cependant, il ne faut pas se tromper d’interprétation. Très vite, on a cru voir des océans de donnée. Cela a donné lieu à la vague du Big Data et au développement de nouveaux outils. Porté par l’engouement pour ces nouvelles technologies, il a fallu un peu de temps avant de cerner les usages et les impacts possibles. Maintenant, ce qui relève de la “datascience” est mieux compris et tout le monde semble avoir repris son sang froid.

Pourtant, une troisième révolution se prépare. En effet, deux tendances se sont développées de manière continue sans que l'on en mesure encore pleinement les conséquences et les possibilités. 

Open Data, pas si “open” que ça, et c’est tant mieux

En réalité, l'aspect "Open" n'est que la partie émergée de l'iceberg. Le véritable point de départ est le constat que les producteurs de données ne sont pas les mieux placés pour exploiter ces données, et qu'il existe une valeur très importante dans les données qui peut être révélée via des usages qui n'ont pas été imaginés au départ. L'Open Data a été poussée par une exigence de démocratie et de transparence. Cela s'est traduit de manière évidente par la pression exercée sur les producteurs de données publiques à qui on a demandé de mettre à disposition ce "bien commun". L'OpenData est une traduction dans la sphère publique d'un enjeu crucial pour toutes les organisations : le partage et la circulation de l'information. 

Le développement massif d'applications a eu pour conséquence que l'essentiel de l'information est aujourd'hui structuré et stocké dans des bases de données. Centralisée et organisée, il est dès lors techniquement beaucoup plus facile d’y accéder. Prenons l'exemple des dépenses publiques. Les citoyens mettent la pression sur les élus pour avoir accès aux comptes publics. Ils ne se contentent plus d'avoir accès aux bilans, ils veulent avoir accès à la source même des données, pour pouvoir eux même explorer les données, chercher l'information qu'ils souhaitent et construire leur propre vision. Ainsi, les collectivités ne peuvent plus se contenter de diffuser des rapports avec des histogrammes pré établis pour communiquer sur la manière dont elles utilisent leur budget. Elles doivent aujourd'hui rendre accessible ces données avec le plus de détail possible (par abus de langage on parle des données "sources", ou données "brutes") et dans des formats ouverts. Et aujourd’hui tout le monde sait que c’est possible (bien que parfois compliqué), car tout le monde considère comme acquis (et à raison) que les puissances publiques ont “informatisé” cette gestion des dépenses. Qu'en est-il au sein des entreprises ? Il est clair que dans ce cas, le "Open" d'OpenData n'a que rarement sa place. Ouvrir ses données vers l’extérieur n’est très généralement pas souhaitable, et utile dans de rares cas. Ouvrir ses données en interne est une autre problématique. Qui peut dire que le service marketing n'a pas intérêt d'avoir accès aux données des ventes ? La généralisation des CRM dans tous les types d'entreprise montre à quel point une part importante de l'information des entreprises, autrefois non consignée, devient donnée structurée. Les portails d’entreprise et le knowledge management n’ont de cesse de se développer. Parallèlement aux wiki d’entreprise, de nouvelles générations d’outils et de pratiques se développent. Le coeur de la solution proposée par Opendatasoft, malgré son nom qui fait immédiatement référence à la tendance OpenData, adresse en réalité le besoin de valorisation interne des données au sein des entreprises. 

API is eating software ?

Une fois qu'on a fait le constat que les données créées à un endroit pouvait être valorisées à un autre, les techniciens ont développé des outils pour permettre d'automatiser ces échanges, afin de permettre aux applications de parler entre elles. Ainsi, il est possible de faire le lien de manière automatique entre un CRM et un logiciel de facturation ou un service de messagerie électronique. Aujourd'hui, c'est un non-sens d'imaginer une solution qui ne soit pas un minimum intégrée à un écosystème. Et si l'on a conscience que l'on ne peut anticiper sur les usages possibles des données, l'idée la plus intelligente est de développer des API. Cette architecture plus souple permet une relative indépendance entre les outils et facilite les intégrations futures.

De la même manière que l'OpenData a fait émerger des standards sur les formats de données (DataPackage, CSV, RTF...), l'OpenAPI est une tendance qui vise à faire émerger des standards, à la fois techniques (Rest, Soap) et métiers (OpenSocial, OpenBankProject...), dans le domaine des API.

Et après ?

Force est de se rendre compte que l'exploitation des données reste technique. Les Hackathons se développent autour de l'OpenData pour créer de nouvelles applications exploitant les nouveaux jeux de données offerts au public. Des services comme Zapier, IFTTT ou Busit permettent de connecter des applications entre elles via leurs API. Doit-on en conclure qu'exploiter des données passe forcément par la création d'une nouvelle application ou la connexion d'applications existantes ? Cela signifierait que tout nouvel usage, qui n’aurait pas été imaginé (ce qu’il est par définition) ne pourrait être exécuté autrement que par un développeur ?

 Au final, cela voudrait dire que je dois nécessairement apprendre à "coder" ma propre application à chaque fois que je souhaite tester une nouvelle idée ?

Les données prolifèrent de manière exponentielle et concentrent de plus en plus de valeur au sein des organisations. Pouvoir exploiter ces données est aujourd'hui plus qu'hier un enjeu stratégique.

Et si ?

Et si demain un expert métier pouvait créer son application sans avoir à coder ? 

De la même manière qu'aujourd'hui on peut créer un site web sans rien savoir du HTML, avec wordpress par exemple. 

Et si on pouvait travailler avec des données comme on écrit un rapport ? 

Quand A.W. m’a contacté via twitter pour me demander s’il pouvait utiliser Kadata pour gérer son cabinet d’avocats, j’ai eu deux réactions :

Oui, bien sûr, on peut utiliser Kadata pour faire du suivi du temps passé !

Mais pour gérer un cabinet d’avocat, il doit bien déjà y avoir des applications pour ça, non?

C’est comme cela que nous avons commencé à travailler ensemble. 

A.W. m’avait vu pitcher Kadata lors de #ParisNewTech, un évènement mensuel où des startup viennent présenter leur projet. Nous nous sommes rencontrés ensuite à Numa, où il m’a expliqué son problème. 

A.W. avait utilisé, au sein de grands cabinets d’avocats, des applications qui avaient été développées sur mesure, qui fonctionnaient très bien. Seul problème, développer une telle application était vraiment trop cher et prendrait trop de temps pour le nouveau cabinet qu’A. venait de créer avec son associé. Il avait donc testé plusieurs applications trouvées sur internet, mais aucune ne répondait exactement à ses besoins : trop compliquées, ne correspondant pas exactement à sa manière de travailler, trop lourdes...

Il m’a ensuite raconté ce qu’il ferait, étape par étape, avec l’application de ses rêves.

Je me suis donc mis à la place d’A.W. et j’ai ouvert Kadata dans sa version prototype de l’époque. Après quelques minutes, je lui ai envoyé le fichier que j’avais réalisé. La réponse ne s’est pas fait attendre:

“Je suis impressionné !

J'ai pris 5 minutes pour regarder ce que tu avais préparé et je pense sincèrement que près de 80 % du boulot est fait...”

Tout est là. Avec Kadata, on se concentre sur le résultat et on arrive très vite à répondre au problème posé.

Bien sûr, 80% du travail était fait, cela voulait aussi dire qu’il restait 20% du travail à faire. Nous avons donc listé les fonctions manquantes. Il s’agit essentiellement de permettre d’éditer directement les factures depuis Kadata, et d’améliorer quelques éléments d’interface. C’est à dire que même à 80%, Kadata permettait à A.W de répondre à son problème et de mettre son vieux fichier Excel à la poubelle.

Alors qu’A.W. pensait avoir une vision très claire de son problème, il s’est rendu compte après quelques semaines que son problème était un peu plus compliqué qu’il n’imaginait. En effet, il était nécessaire de pouvoir affecter un taux horaire par collaborateur par client, et non pas pour l’ensemble des clients. Nous étions passés à côté de ce point. Nous avions conçu Kadata exactement dans cette perspective : il est très difficile de savoir au premier coup ce qu’il faut faire, et les besoins peuvent évoluer. C’était donc le moment de vérité. Arriverions-nous à faire évoluer l’app pour répondre au problème ? Et bien oui, et c’était encore plus simple que nous l’imaginions. Nous nous sommes rendu compte à cette occasion que nous pouvions même améliorer l’expérience utilisateur en améliorant la manière de définir des valeurs par défaut, et nous avons donc ajouté un élément à notre roadmap!

Faut-il le rappeler, la masse de données que nous produisons chaque jour augmente de manière exponentielle. La révolution des TIC nous a plongé dans cette nouvelle ère où tout est digitalisé. Collecter des données et des métadonnées n’a jamais été aussi facile. La multiplication des capteurs, l’Internet des Objets (IoT), les médias sociaux, etc. produisent quotidiennement des téraoctets de nouvelles données. 

Cela implique un phénomène nouveau parfaitement bien retranscrit par Eric Ries dans ce Best Seller et maintes fois cité “Lean Start-up”: l’émergence d’un nouveau processus de production, qui repose essentiellement sur la capacité à mesurer.

Et pour mesurer, il faut de la donnée. 

Bien sûr, il y a beaucoup d’objections à faire au dogme 

“If you can’t measure it, you can’t manage it”. 

Malgré la tendance décrite par Eric Ries, la mesure n’est pas la finalité première de toute donnée. La majorité des entreprises ne sont pas Google ou Facebook, Über ou AirBnB. Toutes n’ont pas un business model qui repose sur l’exploitation d’une masse de données conséquente. Toute activité génère de l’information, et l’exploitation de cette information de manière discrète, la donnée en tant que tel, est la raison première d’être de la donnée.

Fichiers clients, catalogues de produits, inventaires, mais également suivi de projet, ressources humaines, gestion de production, factures, fiches d’activité... Pour la majorité des organisations, l’essentiel des bases de données ont des volumes inférieurs à la centaine de mégaoctets. Ce sont des données très généralement structurées, créées/collectées/(numérisés) directement et manuellement par le personnel de l’organisation. Ce n’est pas un fait nouveau. Si l’on parle de Small Data aujourd’hui, c’est qu’il était nécessaire de trouver un terme pour parler de ce que l’on faisait avant l’arrivée de solutions techniques recouvertes par le terme BigData. 

Le Small Data s’intéresse au processus d’émergence de données. Il s’agit d’une démarche bottom-up, c’est-à-dire initiée par le producteur de la donnée et non par la mise en oeuvre d’une solution technique. 

Le Small Data est avant tout un enjeu de productivité et d’organisation de l’activité. Assurer la qualité des données, éviter les saisies multiples, s’adapter à l’évolution de l’activité, optimiser la collaboration, assurer l’homogénéité de l’information... autant d’aspects recouverts par le Small Data.

Développer une approche data-centric et imaginer les multiples possibilités de valoriser la donnée sera primordial pour le développement de l’entreprise de demain. Mais il est important de ne pas passer à coté de l’essentiel, la gestion de la donnée au quotidien.

Le Small Data, nouveau buzzword? Malgré sa nouvelle dénomination, ce n’est pas un sujet nouveau, mais pourtant toujours d’actualité. Il s’agit d’une thématique à part entière, qui a sa place à côté d’autres concepts comme l’OpenData, le Smart Data, le FrictionLess Data, etc. 

Sources:

“Lean Start-Up”, Eric Ries

“The data Revolution”, Rob Kitchin

Changer d’application est souvent une étape difficile, surtout lorsque une part importante de l’activité d’une entreprise repose justement sur l’application en question. Combien d’entreprises continuent d’utiliser des outils peu performants, parfois même contreproductifs, tout simplement par crainte de perdre des informations critiques ?

C’est pour cette raison que nous avons lancé Kadata #LeLab, un programme spécifique pour accompagner les entreprises dans cette phase de migration. Dans ce cadre, nous accompagnons les entreprises dès la phase de diagnostic en identifiant avec elles les processus qui pourraient être optimisés. Nous les accompagnons ensuite à exploiter ces réservoirs de gain de productivité grâce à Kadata.

Dans 80% des cas, Excel n’est pas le bon outil, et s’il rend bien des services, il est également responsable d’une perte de productivité incroyable.

Souvenez-vous de cette fameuse formule :

  =RECHERCHEV(A2;$G$2:$I$7;2;FAUX)

qui un jour a décidé de hurler un horrible “#N/A”, et qui vous a fait perdre votre temps !

Croiser des données avec RECHERCHEV, recopie de formules, cellules fusionnées … sont autant d’exemples symptomatiques de données qui ne devraient pas être dans un fichier Excel.

Ce qu’il vous faut alors, c’est une base de données.

Access, le grand frère d’Excel ? N’en parlons même pas, c’est pour les informaticiens.

Assurer la sécurité de ses différents comptes sur Internet n’est bien sur pas une option. Mais quelle stratégie adopter ?

Se connecter via un service d’authentification tiers, tel Facebook, Google ou autre (en s’appuyant techniquement sur un protocole d’autorisation comme OAuth). Cela a l’avantage de pouvoir centraliser et visualiser l’ensemble des applications utilisées et de bénéficier d’un niveau de sécurité élevé à un seul endroit (unique mot de passe complexe + éventuellement sécurisation supplémentaire, via SMS par exemple). Cependant, certains seront réticents à l’idée de lier leurs différents comptes de cette manière.

Multiplier les mots de passe. C’est souvent une mauvaise stratégie: soit on utilise un mot de passe très simple, soit on utilise le même mot de passe sur toutes les applications, ou encore on utilise un outil de sauvegarde de mot de passe (c’est toujours mieux que de les noter en clair ou sur un post-it, qui est pourtant une pratique courante...). Bref, dans tous ces cas, on se retrouve avec généralement une sécurité moindre, et on finit très souvent par demander la mise à jour du mot de passe par courriel.

Cela nous amène tout naturellement vers une autre alternative (et c’est celle que nous avons choisi pour Kadata) : sécuriser l’accès à l’application via un mot de passe temporaire envoyé par courriel. Un mot de passe à 4 chiffres valable uniquement 15 minutes. C’est très simple pour l’utilisateur : l’authentification n’est redemandée que pour l’accès aux données sensibles, le code apparait directement dans l’objet du courriel (ce qui permet de ne pas avoir à l’ouvrir). Niveau sécurité, c’est parfait. Pour l’utilisateur? Aujourd’hui, personne ne s’en plaint. Et vous, qu’en pensez-vous? 

L'équipe de Kadata organise des évènements pour parler Small Data.

C'est quoi le Small Data? Ce sont toutes ces données qui foisonnent dans les entreprises. Au coeur de votre métier (gestion de production) ou en support (comptabilité, marketing, RH).

Pendant un moment, il était très tendance de parler de Big Data (et la mode n'est pas terminée). Tout le monde veut sa solution Big Data. Finalement, on se rend compte que dans beaucoup de cas, les données ne sont pas si "Big" que ça (surtout que les capacités de stockage et de traitement d'aujourd'hui ne sont pas celles d'hier), et que les usages ne sont pas véritablement ceux ciblés par les techno "Big Data". Bref, on a un peu oublié ce qu'on faisait avant, quand les problèmes n'étaient pas de savoir comment on allait pouvoir faire du machine learning sur des To de données en temps réel.

Nous avons donc décidé de mettre un nom sur ces données, sur ce qui n'est pas du Big Data, mais en essayant d'élargir et de donner un nouveau souffle à ce champ de la gestion de données d'entreprise.

Nous serons ravi d'échanger sur le Small Data dans le cadre de notre prochain meetup: restez informés!

Small Data et Kadata

Aujourd’hui, 90% des applications dans les entreprises sont des fichiers Excel. Pour beaucoup, le tableur est le réflexe. C'est l'outil par défaut (sinon le seul qui soit accessible à tous, même et surtout les moins techniques), et pourtant un outil qui n'est pas fait pour gérer des bases de données. Un tableur, c'est au départ une calculette survitaminée. Pourquoi demander à Excel de gérer des listes déroulantes ou des cases à cocher?

Bref, nous pensons qu'il manquait un outil pour voir ses données autrement qu'en deux dimensions. Pourtant, penser "relationnel" n'est peut être pas évident aux premiers abords. Nous travaillons donc à préciser l'interface de kadata pour que structurer ses données soit vraiment intuitif, que l'on puisse laisser la technique de côté et se concentrer sur le coeur du problème: ce que l'on fait au quotidien. 

Deux autres actualités :

Nous avons retravaillé notre site pour qu'il soit plus en phase avec le projet kadata :

Kadata apporte une véritable valeur ajoutée aux TPE, PME et petites équipes. Nous devions le refléter, c'est fait avec notre nouveau visuel.

C'est une application intuitive, utilisable par tous (sans vocabulaire technique). Nous avons amélioré les modèles et les exemples, et nous continuerons à enrichir régulièrement cette section.

Nous espérons que vous serez conquis par notre nouveau design!

Kadata est à peine sorti que nous pensons déjà aux prochaines fonctionnalités. Et oui, on ne va pas s'arrêter là! 

Vous avez déjà été nombreux à demander de pouvoir importer des données existantes pour commencer à travailler. Ça va donc venir assez vite! Mais dites nous comment vous voyez ça (des formats de fichiers spécifiques?) Si vous avez déjà fait des imports de données dans d'autres applications, qu'est ce que vous avez aimé, détesté, qu'est ce qui vous a manqué?)

Nous avons aussi plein d'autres idées en tête:

connexion de l'application à des services de stockage en ligne (dropbox, Google drive, ou un tout autre service que vous utilisez)

connexion à d'autres listes: Calendriers (listes d’évènements), contacts...kadata se connecte et se synchronise à tout ce qui ressemble à une collection de données

formules de calcul avancées:  faire référence à une cellule calculée ou à une cellule d'une autre collection dans des formules de calcul 

fonctions de partage et de collaboration : la possibilité de travailler à plusieurs sur un même projet, de rendre publiques des collections, de permettre à d'autres utilisateurs de saisir des données...

gestionnaire de filtres: filtrer des collections et sauvegarder les filtres pour les réutiliser

moteur de recherche: retrouver rapidement une ligne ou un ensemble de ligne qui répondent à certains critères

timeline: une timeline pour explorer la vie de chaque élément: quelles sont les modifications qui ont été apportées, par qui et quand, tout ça via une interface si simple qu'il n'y a plus aucune question à poser

cartographie: Saisissez de l'information géographique (points d’intérêts, périmètres, surfaces) et visualisez vos collections sous forme de cartes

mise en forme des colonnes: ajoutez des symboles, des couleurs sur vos collections

tableaux croisés dynamiques: analysez vos collections grâce à des tableaux croisés

graphiques et tableaux de bords: des graphiques pour visualiser vos données, directement accessible depuis la page d'accueil

Après plusieurs mois d'efforts et de réflexion, nous sommes heureux de lancer aujourd'hui kadata, notre réponse simple pour structurer intuitivement ses données. 

On a déjà écrit un article pour expliquer d'où venait le problème et quel serait pour nous la réponse idéale. 

En résumé, si vous êtes seul ou au sein d'une petite équipe et que vous utilisez excel à défaut d'un logiciel de base de données pour gérer au quotidien des listes de données, kadata est très probablement fait pour vous!

Les outils de gestion de données et la mise en place d’outils tels que les PGI (Progiciels de Gestion Intégrée autrement appelés ERP pour Enterprise Resource Planning) font l’objet de nombreuses publications.

L’intérêt pour ces solutions “globales” masque une réalité de terrain qui est la gestion de nouvelles données au quotidien, dans les cas qui ne peuvent être pris en compte par ces solutions dont l'approche de la structuration est essentiellement descendante.

L’approche traditionnelle est de considérer que l’on peut analyser les pratiques à un instant t et concevoir un système permettant de saisir et rationaliser les processus. Or, chaque individu dans l’entreprise a besoin d’outils qui correspondent à ses méthodes de travail. Cette approche n’est donc pas apte à saisir les processus qui émergent quotidiennement du fait des pratiques. Les échecs de mise en place d’outils de gestion de données dans les entreprises sont souvent liés au fait que ces solutions ne peuvent gérer efficacement l’émergence de ces nouveaux processus et délivrent des outils qui se trouvent finalement soit inadaptés soit rapidement obsolètes.

Pour comprendre mieux répondre aux besoins des utilisateurs, nous nous sommes penchés sur la question qui nous semble être au coeur du problème : à quel moment et pour quelles raisons émerge le besoin de structurer les données?

  Nous avons fait plusieurs observations sur la place des données et leur émergence au sein des entreprises.

Au niveau opérationnel, la pratique fait émerger ou évoluer des processus. De ce fait, l’outil sur-mesure et intégré ne peut pas précéder les pratiques et aura toujours un temps de retard.

Nombreuses bases de données naissent du fait d’une ou plusieurs personnes au coeur des processus, collaborant de manière resserrée. C’est seulement dans une deuxième phase que la base de données est généralisée et partagée à une échelle plus large.

La standardisation d’un processus est un travail itératif. La structure des premières données saisies est rarement la structure définitive.

La modélisation d’une pratique est une prise de conscience. Ce travail peut être favorisée par une représentation de ce modèle qui permette de le manipuler et de le tester.

La multiplication des fichiers personnels est liée au fait que personne n’attend l’outil sur-mesure pour commencer à travailler.

Industrialiser des processus métiers n’est pas systématiquement pertinent. C’est un projet qui a un coût et qui nécessite de “figer” les processus. Ce n’est donc pas adapté à toutes les situations: si ce n’est parfois pas nécessaire, ce peut même être contre productif (notamment pour des missions courtes ou les expérimentations).