Blog

Quand nous avons commencé à reconstruire Monica, je savais que les relations feraient partie des sujets qu'il nous faudrait repenser. Ce que je n'avais pas prévu, c'est à quel point il serait difficile ne serait-ce que de définir ce qu'est une relation.

Un CRM personnel doit savoir comment les gens sont liés entre eux. Quelqu'un est votre mère, votre frère, votre ami, votre collègue ou votre conjoint. Monica gère cela depuis des années, et du point de vue de l'utilisateur, c'est une fonctionnalité assez simple : vous sélectionnez une personne, vous choisissez une relation, et c'est terminé.

Malheureusement, concevoir ce qui se passe derrière ce petit menu déroulant n'est pas simple du tout.

Même les relations simples ne le sont pas tant que ça

Disons que Monica est la sœur de Ross. Du point de vue de Monica, Ross est son frère. Les deux phrases décrivent la même relation, mais les mots que nous employons dépendent de la personne que nous regardons.

La même chose se produit partout dans une famille. Rachel est la mère d'Emma, tandis qu'Emma est la fille de Rachel. La tante de quelqu'un a une nièce ou un neveu. Une grand-mère a une petite-fille ou un petit-fils.

D'autres relations ne fonctionnent pas comme ça. Chandler et Joey sont amis. Le mot est le même quel que soit le côté que l'on regarde. Les cousins et les collègues peuvent fonctionner de la même façon.

Nous avons donc déjà des comportements différents. Parfois une relation change de nom selon le côté que l'on regarde, parfois non, et parfois le mot que nous employons dépend du genre de l'une des deux personnes.

Et c'est la partie facile.

Les familles sont compliquées

Imaginez deux personnes qui se marient et ont deux enfants. Elles divorcent. L'une d'elles se remarie avec quelqu'un qui a déjà des enfants d'une autre relation, et peut-être qu'elles ont ensemble un enfant de plus.

Ce n'est pas une famille particulièrement inhabituelle, mais nous avons désormais des parents, des enfants, des frères et sœurs, des demi-frères et demi-sœurs, des beaux-enfants, des beaux-parents, des conjoints et des ex-conjoints.

Cela soulève aussi des questions auxquelles je ne crois pas qu'il existe toujours une réponse universelle. Si vous divorcez, votre belle-mère cesse-t-elle d'être votre belle-mère ? Techniquement, peut-être. Mais si vous la connaissez depuis vingt ans et que vous la considérez toujours comme faisant partie de votre famille ? Elle ne cesse certainement pas d'être la grand-mère de vos enfants simplement parce que votre mariage est terminé.

Il y a ensuite les parents biologiques, les parents adoptifs, les familles d'accueil et les tuteurs. Quelqu'un peut avoir plusieurs personnes qu'il considère comme ses parents, et ces relations ne signifient pas nécessairement la même chose. Il y a les membres de la famille dont on s'est éloigné, les gens qui considèrent quelqu'un comme un frère ou une sœur sans aucun lien biologique, les anciens partenaires qui restent très proches, et les parents qui élèvent des enfants ensemble sans plus former un couple.

Le bel arbre généalogique que nous avons tendance à imaginer en réfléchissant à ce problème ne survit pas au contact de beaucoup de familles réelles.

Et même quand la structure familiale est simple, les relations changent. La personne qui est votre conjoint aujourd'hui sera peut-être votre ex dans cinq ans. Cela ne veut pas dire que l'ancienne relation devrait simplement disparaître. Le fait que deux personnes ont été mariées pendant quinze ans reste une partie de leur histoire, même si elles ne le sont plus.

Les relations ont un passé, ce qui rend également problématique le fait de ne représenter que leur état actuel.

Deux personnes ne sont pas forcément d'accord sur leur relation

Les relations familiales nous donnent au moins quelques faits sur lesquels travailler. L'amitié est encore moins précise.

Si Monica considère Rachel comme une amie proche, est-ce que Rachel considère nécessairement Monica comme une amie proche ? Nous n'en avons aucune idée.

Le même problème existe avec les mentors, les connaissances et bien d'autres relations. Quelqu'un peut considérer une personne comme son mentor même si cette personne n'emploierait jamais ce mot elle-même. Quelqu'un peut considérer un vieil ami comme pratiquement de la famille alors que l'autre y voit une personne qu'il a connue il y a des années.

Cela compte beaucoup dans Monica, parce que l'information n'a pas pour but de décrire un graphe social objectif. Ce sont vos informations sur les gens de votre vie.

Quand vous écrivez que quelqu'un est votre ami, vous décrivez la relation telle que vous la comprenez. Monica n'a pas la version de l'autre personne, et dans bien des cas il n'existe probablement pas de réponse unique et correcte.

Cela devient particulièrement étrange quand un logiciel essaie de transformer les relations en quelque chose de mesurable. Est-ce que quelqu'un est un meilleur ami parce que vous le voyez chaque semaine ? Est-ce qu'un ami que vous n'avez pas vu depuis cinq ans compte moins qu'un collègue avec qui vous parlez tous les jours ? Évidemment, la fréquence nous dit quelque chose sur une relation, mais elle ne nous dit pas ce que cette relation signifie pour quelqu'un.

Le temps ne rentre pas bien dans les cases non plus

Un collègue peut devenir un ami. Un ami peut devenir un conjoint. Un conjoint peut devenir un ex, et des années plus tard la même personne peut redevenir un ami.

Si Monica enregistre que deux personnes sont mariées et qu'elles divorcent ensuite, qu'est-ce qui devrait arriver au mariage ? Le supprimer rendrait l'information actuelle correcte, mais effacerait aussi quelque chose d'assez important de leur histoire.

Nous pourrions conserver des dates, sauf que les gens ne les connaissent souvent pas. Je peux savoir que deux amis ont été ensemble sans avoir la moindre idée de quand ils ont commencé à se fréquenter ni de quand exactement ils se sont séparés. Exiger des dates précises rendrait le modèle plus propre tout en rendant le produit bien plus agaçant à utiliser.

Rien ne garantit non plus que les relations passent proprement d'un état à un autre. Les gens ne se réveillent pas nécessairement un matin en passant de « ami » à « conjoint ». Certaines relations ont un début clair, comme un mariage. Beaucoup d'autres non.

La base de données aimerait beaucoup que nous sachions quand tout a commencé et quand tout s'est terminé. La plupart du temps, nous ne le savons pas.

L'anglais n'est pas le modèle du monde entier

Autre problème : la plupart des premiers exemples qui viennent à l'esprit sont fondés sur l'anglais.

L'anglais utilise « cousin » pour un grand nombre de relations familiales, alors que d'autres langues peuvent être beaucoup plus précises. Le mandarin, par exemple, a des mots différents pour les cousins selon le côté de la famille d'où ils viennent, leur genre et parfois leur âge. Le suédois distingue les quatre grands-parents : mormor est la mère de votre mère, morfar le père de votre mère, farmor la mère de votre père et farfar le père de votre père. L'anglais nous donne simplement « grandmother » et « grandfather ».

Le coréen fournit un autre exemple. Même quelque chose d'aussi simple que « grand frère » change selon qui parle. Un homme appelle son grand frère hyeong, une femme l'appelle oppa. Le vocabulaire des relations contient une information qui n'est pas présente dans le mot anglais « brother ».

Cela compte pour Monica, parce que Monica est traduite dans de nombreuses langues et utilisée dans le monde entier. Nous ne pouvons pas concevoir tout le système de relations en partant du principe que l'anglais contient la liste canonique des relations et que toutes les autres langues n'ont qu'à traduire ces mots.

C'est un problème que nous avons déjà rencontré dans Monica, et la reconstruction ne le fait pas disparaître par magie.

La famille n'est même pas le plus dur

Au moins, les relations familiales ont généralement un nom. Le reste de nos relations est beaucoup moins structuré.

« Ami » peut décrire quelqu'un que vous connaissez depuis trente ans et à qui vous parlez chaque semaine, mais aussi quelqu'un que vous voyez deux fois par an et à qui vous tenez énormément. Un collègue peut être la personne assise à côté de vous tous les jours, ou quelqu'un avec qui vous avez travaillé il y a quinze ans.

Et les gens n'entrent pas dans une seule catégorie à la fois. Quelqu'un peut être votre collègue, votre ami et votre ancien colocataire. Votre associé peut aussi être votre frère. Votre voisin peut être le parent de la meilleure amie de votre fille.

Parfois, c'est le contexte lui-même qui compte. Vous connaissez quelqu'un parce que vous êtes allés à l'école ensemble, avez joué dans la même équipe, habité le même immeuble ou travaillé sur le même projet. « Ami » est peut-être techniquement correct, mais on perd l'information qui explique pourquoi cette personne fait partie de votre vie.

C'est là qu'une question simple comme « comment connaissez-vous cette personne ? » devient étonnamment difficile à traiter avec un seul champ.

Une relation peut en impliquer beaucoup d'autres

Supposons que Ross soit le frère de Monica et que Ross ait un fils qui s'appelle Ben. Nous comprenons immédiatement que Monica est la tante de Ben.

Un logiciel peut arriver à la même conclusion. Et une fois qu'il commence à le faire, il peut continuer.

Des parents impliquent des enfants. Des enfants qui ont les mêmes parents sont peut-être frères et sœurs. Des frères et sœurs qui ont des enfants créent des tantes, des oncles, des nièces et des neveux. Ajoutez une génération et vous avez des grands-parents et des petits-enfants. Très vite, un petit nombre de relations peut produire un graphe familial bien plus grand.

Mais le fait qu'un logiciel puisse déduire quelque chose ne veut pas dire qu'il devrait le faire.

Le nouveau conjoint d'un parent n'est pas automatiquement un parent de l'enfant. Deux personnes qui partagent un parent sont peut-être techniquement demi-frères ou demi-sœurs, mais elles ne se connaissent peut-être pas. Les informations dont Monica dispose peuvent aussi être tout simplement incomplètes. Et même si la relation familiale est techniquement correcte, ce n'est peut-être pas celle que les personnes concernées emploieraient pour se décrire.

Chaque fois que le logiciel déduit une relation de plus, il se donne aussi une occasion de plus de se tromper.

Il y a plus de questions que de réponses

Plus nous travaillons sur ce sujet, plus nous trouvons de cas particuliers.

Monica devrait-elle se souvenir de l'histoire d'une relation ou seulement de son état actuel ? Deux personnes peuvent-elles avoir plusieurs relations en même temps ? « Meilleur ami » est-il une relation différente de « ami », ou bien autre chose ? Que se passe-t-il quand nous connaissons la mère de quelqu'un mais que cette mère n'est pas un contact dans Monica ? Comment décrire des relations qui comptent pour nous mais qui n'ont pas de nom pratique ?

Certaines de ces questions sont des problèmes de base de données. La plupart ne le sont pas.

Le plus difficile est de décider ce que nous voulons dire quand nous disons que deux personnes ont une relation, parce que les humains n'emploient pas ce mot avec quoi que ce soit d'approchant la précision qu'une base de données préférerait.

Depuis l'interface, tout cela finira peut-être par se résumer à quelques mots sur le profil de quelqu'un : mère, frère, ami, collègue.

Réussir ces quelques mots est l'un des problèmes les plus difficiles auxquels nous faisons face en reconstruisant Monica.

Ceci est un nouvel article de la série Building Monica, dans laquelle j'écris sur la reconstruction complète de Monica. La plupart des articles de cette série porteront probablement sur le produit lui-même : les relations, les rappels, la personnalisation, les activités, la vie privée, et toutes les questions qui accompagnent la tentative de représenter la vie des gens dans un logiciel. Mais reconstruire une grande application produit aussi de plus petites choses en chemin. LaraDB en fait partie.

Pendant que je travaillais sur Monica v3, je me suis rendu compte que je passais beaucoup de temps à regarder directement la base de données. Ce n'est pas particulièrement inhabituel quand on construit une application Laravel. On crée un contact et on vérifie ce qui a été écrit. On crée une relation et on inspecte les lignes concernées. On modifie un rappel et on vérifie les dates. On lance une action, on rafraîchit les données, on suit une clé étrangère, et on recommence de nombreuses fois dans la journée.

Il existe déjà beaucoup de bonnes façons de faire cela. Tinker est utile, mais pas simple ni rapide à utiliser. Des applications comme TablePlus, DBeaver, phpMyAdmin ou Adminer peuvent être très utiles, mais pas pour une consultation rapide. J'utilise TablePlus régulièrement, surtout quand j'ai besoin d'écrire des requêtes, de modifier des données ou d'inspecter le schéma en détail. Mais la plupart du temps, en développant Monica, je n'avais pas besoin d'un outil de gestion de base de données. Je voulais seulement un moyen rapide de voir ce qu'il y avait dans la base, sans quitter l'application sur laquelle je travaillais déjà.

C'était l'idée de départ de LaraDB. Installer une dépendance de développement, aller sur /db, et voir la base de données.

composer require --dev monicahq/laradb

Ce que vous obtenez est très simple. Les tables s'affichent à gauche, les lignes à droite, et la page tourne à l'intérieur de l'application Laravel elle-même. LaraDB prend en charge SQLite, MySQL et MariaDB, ainsi que PostgreSQL.

Un navigateur plutôt qu'un gestionnaire de base de données

La décision la plus importante que nous avons prise a été de garder LaraDB en lecture seule. Il n'y a pas de bouton de modification, pas de bouton de suppression, pas de formulaire d'insertion ni de console SQL. Les deux routes exposées par le paquet sont des routes GET, et le paquet n'émet que des instructions SELECT.

C'est en partie une décision de sécurité, mais c'est surtout une question de périmètre. Il existe déjà des outils matures pour gérer des bases de données, et reproduire une partie de leurs fonctionnalités à l'intérieur de Laravel ne rendrait pas LaraDB plus utile pour le problème que nous essayions de résoudre.

Le paquet évite également d'accepter des identifiants ou des requêtes arbitraires venant du navigateur. Une table demandée doit d'abord exister dans le schéma découvert par le pilote. Les identifiants sont échappés selon le moteur de base de données. Les valeurs utilisées pour suivre les clés étrangères sont passées en paramètres liés. Il n'y a pas d'interface pour soumettre du SQL arbitraire, parce que le SQL arbitraire ne fait pas partie de la raison d'être du paquet.

Un petit outil peut rester compréhensible s'il a une mission très précise. LaraDB est censé répondre à la question de ce qui se trouve actuellement dans la base de données et de la manière dont ces lignes sont liées entre elles. Il n'est pas censé devenir un remplaçant d'un vrai client de base de données.

Ce dont nous avons fini par avoir besoin

L'interface reflète ce périmètre étroit. LaraDB liste les tables du schéma courant et affiche leurs lignes dans un tableau dense. Les types de colonnes sont indiqués, les clés primaires et étrangères sont identifiées, les valeurs NULL se distinguent visuellement des chaînes vides, et les valeurs longues sont tronquées pour que les grandes colonnes de texte ou de JSON ne rendent pas la page inutilisable.

Les clés étrangères se sont révélées être l'une des fonctionnalités les plus utiles pour Monica. Si une colonne référence une autre table, sa valeur peut être suivie directement. Un clic ouvre la table référencée, filtrée sur la ligne correspondante. C'est particulièrement utile dans Monica v3, parce qu'un nombre croissant de domaines y sont représentés par des relations explicites entre plusieurs tables plutôt que par de gros enregistrements autonomes.

La page expose aussi un peu de contexte sur la base de données et la requête en cours. Selon ce que le moteur de base de données met à disposition, LaraDB peut afficher le moteur et sa version, le nom de la base, sa taille, le nombre d'index et d'autres métadonnées propres au moteur. Pour la page en cours, il montre également l'instruction SQL qui a produit le résultat et le temps qu'a pris la requête.

Il existe aussi une représentation JSON d'une table. C'était peu coûteux à ajouter une fois la couche base de données séparée du rendu HTML, et cela s'est avéré utile pour inspecter des données en dehors de la page elle-même.

Le frontend est volontairement autonome. Le paquet embarque son propre CSS et son propre JavaScript, et ne dépend pas de la chaîne d'assets de l'application hôte. Installer LaraDB ne devrait pas obliger à ajouter une configuration Tailwind, une dépendance Alpine ou une étape de build supplémentaire à un projet existant.

L'abstraction de la base de données est devenue le vrai travail

Afficher des lignes dans un navigateur est simple. Prendre en charge SQLite, MySQL et PostgreSQL de manière cohérente, c'est là que la plus grande partie du travail intéressant a fini par se trouver.

Les moteurs diffèrent nettement dans la façon dont ils exposent le schéma et les métadonnées de la base. Lister les tables, décrire les colonnes, trouver les clés primaires, résoudre les clés étrangères, compter les lignes et récupérer les informations au niveau de la base demandent des requêtes différentes selon le moteur. Même des détails comme l'échappement des identifiants doivent être traités correctement plutôt que comme une opération SQL générique.

LaraDB masque ces différences derrière une petite interface de pilote. La couche Laravel demande des tables, des colonnes, des lignes et des métadonnées sans avoir besoin de savoir si la connexion sous-jacente est SQLite, MySQL ou PostgreSQL.

Une partie simplifiée du contrat ressemble à ceci :

public function listTables(): array;

public function getColumns(string $table): array;

public function getRowCount(
    string $table,
    ?RowFilter $filter = null,
): int;

public function getRows(
    string $table,
    int $page,
    int $perPage,
    ?RowFilter $filter = null,
): TablePage;

public function getForeignKeys(string $table): array;

Chaque pilote de base de données implémente ces opérations différemment, tandis que le reste de LaraDB travaille avec les objets de résultat communs renvoyés par l'interface.

Une conséquence intéressante de cette conception est que le cœur du code de lecture de la base ne dépend pas du tout de Laravel. Il travaille directement avec PDO. Laravel s'occupe de la découverte du paquet, de la configuration, du routage et du rendu, mais l'inspection de la base peut être utilisée séparément.

use LaraDb\DriverFactory;

$pdo = new PDO('sqlite:database.sqlite');
$driver = DriverFactory::fromPdo($pdo);

foreach ($driver->listTables() as $table) {
    echo $table->name;
}

Lecture seule ne veut pas dire inoffensif

Le fait que le paquet soit en lecture seule l'empêche de corrompre la base de données, mais cela ne rend pas anodin le fait d'exposer cette base. Un navigateur de base de données peut révéler chaque ligne de chaque table à toute personne capable de l'atteindre, ce qui est évidemment une préoccupation sérieuse pour une application comme Monica.

Pour cette raison, LaraDB est conçu pour être installé comme dépendance de développement.

composer require --dev monicahq/laradb

Un déploiement de production normal, fait avec composer install --no-dev, ne contiendra pas le paquet. LaraDB est aussi désactivé par défaut en dehors de l'environnement local, et ses routes utilisent par défaut les middlewares web et auth lorsqu'elles sont activées.

Les petites choses qui sortent d'une grande reconstruction

Quand j'ai commencé la série Building Monica, je m'attendais à ce que l'essentiel des textes porte sur les grandes décisions d'architecture et de produit derrière Monica v3. Cela restera le cas. Mais je veux aussi documenter certains des outils et des idées plus modestes qui sortent de cette reconstruction, parce qu'ils font partie du travail eux aussi.

LaraDB n'est pas une pièce majeure de Monica v3, et il ne cherche pas à devenir un produit important en soi. C'est simplement un petit outil de développement qui a supprimé une gêne récurrente pour nous. Le paquet est utile précisément parce que son périmètre est limité, et j'aimerais qu'il le reste.

Si vous travaillez sur des applications Laravel et que vous ouvrez souvent un client de base de données uniquement pour inspecter ce que votre code vient d'écrire, LaraDB pourrait vous être utile également.

composer require --dev monicahq/laradb

Puis allez sur /db.

Le code source est disponible sur github.com/monicahq/laradb.

Ceci est le premier article d'une série intitulée Building Monica. Je veux me servir de cette série pour documenter la reconstruction complète de Monica, le CRM personnel open source. Je parlerai des problèmes que nous essayons de résoudre, des décisions que nous prenons en chemin, et probablement de certaines choses qui ne se passent pas comme prévu.

Il y a presque dix ans, j'ai commencé à construire Monica parce que j'étais incapable de me souvenir de quoi que ce soit à propos des gens. J'oubliais le prénom de l'enfant de quelqu'un, ce dont nous avions parlé la dernière fois que nous nous étions vus, ou une chose importante que l'on m'avait confiée quelques mois plus tôt. Je voulais un endroit où noter tout cela, surtout pour compenser ma mauvaise mémoire, alors j'ai commencé à utiliser un CRM professionnel.

Ce n'était pas une très bonne solution. Le logiciel était conçu pour des commerciaux, ce que je n'étais pas, et je n'avais pas particulièrement envie de payer pour un outil censé m'aider à gagner de l'argent alors que je voulais simplement me souvenir de choses concernant mes amis et ma famille. J'ai cherché quelque chose de plus adapté, sans rien trouver, alors j'ai décidé de le construire moi-même.

Ce petit projet est finalement devenu Monica. J'ai mis le code sur GitHub, je l'ai publié sur Hacker News, et les choses se sont un peu emballées à partir de là. Il s'est avéré que je n'étais pas le seul à chercher quelque chose comme ça. Alexis m'a rejoint comme cofondateur, et au fil des années des milliers de personnes ont utilisé Monica, contribué au code, traduit le projet, signalé des bugs et installé l'application sur leurs propres serveurs. Le projet compte aujourd'hui plus de 25 000 étoiles sur GitHub et est devenu l'un des CRM personnels open source les plus connus.

Je suis très fier de ce que Monica est devenu. Mais après y avoir travaillé aussi longtemps, j'en suis arrivé à un point où la version actuelle n'est plus le CRM personnel que je construirais aujourd'hui.

Presque dix ans de décisions

Quand j'ai commencé Monica, je n'avais évidemment pas dix ans d'expérience à réfléchir à la façon de représenter les relations humaines dans un logiciel. La plupart des décisions ont été prises au moment où un problème apparaissait. Il nous fallait des contacts, alors j'ai construit des contacts. Il nous fallait des relations, alors j'ai ajouté des relations. Puis sont venus les rappels, les activités, les cadeaux, les notes, les animaux, les adresses et bien d'autres fonctionnalités.

Il n'y a rien de particulièrement mal à construire un logiciel de cette manière. C'est comme ça que Monica a grandi, et beaucoup de ces décisions avaient du sens à l'époque. Mais après presque dix ans, elles s'accumulent. Les nouvelles idées doivent contourner des décisions prises des années plus tôt, et ce qui ressemblait à des détails d'implémentation devient peu à peu une contrainte sur ce que l'on peut faire du produit.

Avec le temps, cela a rendu certaines parties de Monica plus difficiles à faire évoluer qu'elles ne devraient l'être. Plus important encore, j'ai changé d'avis sur certaines des décisions d'origine.

Que construirais-je aujourd'hui ?

À un moment donné, j'ai commencé à me poser une question simple : si Monica n'existait pas et que je devais construire un CRM personnel aujourd'hui, avec tout ce que j'ai appris au cours de la dernière décennie, à quoi ressemblerait-il ?

Cela a rapidement mené à des questions bien plus fondamentales que celle des fonctionnalités que Monica devrait avoir. Qu'est-ce qu'une personne, exactement, dans Monica ? Comment les relations entre les personnes devraient-elles fonctionner ? Comment Monica devrait-il représenter l'utilisateur lui-même ? Que se passe-t-il quand ce qui compte dans la vie de quelqu'un n'est pas une autre personne, mais un animal, une organisation ou tout autre chose ? Comment les rappels devraient-ils fonctionner alors que les relations humaines ne suivent pas naturellement un calendrier ? Que devrait représenter une activité ? Et, pour commencer, quelle part de tout cela Monica devrait-il définir à votre place ?

Les relations sont un bon exemple. Enregistrer que Monica est la sœur de Ross ne paraît pas très compliqué. Mais si Monica est la sœur de Ross, alors Ross est aussi le frère de Monica. Une relation de parent implique une relation d'enfant. Certaines relations ont un sens, d'autres non. Les vraies familles comportent des divorces, des remariages, des beaux-enfants, des demi-frères et demi-sœurs, des adoptions et toutes sortes de configurations qui n'entrent pas proprement dans une liste prédéfinie. Les cultures décrivent aussi les liens familiaux différemment.

J'ai passé beaucoup de temps à réfléchir à cela pour la nouvelle version, et je vois désormais les relations comme un domaine à part entière plutôt que comme un attribut rattaché à un contact. Cela me paraît évident aujourd'hui. Ça ne l'était pas quand nous avons conçu les premières versions de Monica.

La personnalisation est un autre sujet sur lequel j'ai changé d'avis. Historiquement, c'est surtout Monica qui a défini ce qu'est un contact et quelles informations on peut stocker à son sujet, et nous avons ajouté de la personnalisation autour de cette structure. Pour la v3, nous voulons inverser cela. Monica proposera toujours de bons réglages par défaut, parce que personne n'a envie de configurer cinquante choses avant d'ajouter son premier contact, mais votre vie ne devrait pas avoir à rentrer dans le schéma de base de données que nous avons jugé bon pour tout le monde.

Dès que l'on commence à changer les choses à ce niveau, redessiner quelques écrans ne suffit plus. Les fondations doivent changer aussi.

Ce que je veux que la v3 soit

Monica v3 n'est pas censée être le produit actuel avec une plus belle interface. L'interface va changer considérablement, et je veux qu'elle soit beaucoup plus ludique et personnelle que la plupart des logiciels que nous utilisons aujourd'hui, mais ce n'est qu'une partie du travail.

Je veux construire un système très puissant pour documenter les personnes et les relations dans la vie de quelqu'un. Optimiser chaque chose pour la simplicité ne m'intéresse pas particulièrement si le résultat est un produit qui ne sait représenter que des vies simples. Je préfère de bons réglages par défaut pour les gens qui ne veulent rien configurer, tout en donnant à ceux qui le souhaitent un contrôle énorme sur le fonctionnement de leur Monica.

Cela veut dire traiter les relations comme des concepts de premier plan et laisser chacun décider quelles informations comptent pour lui. Monica doit savoir gérer bien plus qu'une liste prédéfinie de champs rattachés à un contact. Le plus difficile sera de faire tout cela sans finir avec un logiciel d'entreprise pour gérer ses amis et sa famille, parce que ce serait assez horrible.

Il y a aussi des choses que je ne veux pas changer. La confidentialité et la propriété des données comptent toujours énormément pour Monica. Le projet restera open source et auto-hébergeable. Si vous devez passer des années à confier à un logiciel certaines des informations les plus personnelles de votre vie, je pense que vous devez garder autant de contrôle que possible sur ces informations.

Je ne veux pas non plus que Monica décide de l'importance que quelqu'un a pour vous. Elle peut vous aider à vous souvenir, à organiser des informations et vous signaler que vous n'avez pas parlé à quelqu'un depuis longtemps. La relation, elle, reste la vôtre à entretenir.

Recommencer avec dix ans d'expérience

« Recommencer » n'est pas tout à fait exact, bien sûr. Quand j'ai créé Monica en 2017, j'avais une idée et un problème que je voulais résoudre. Cette fois, nous avons presque dix ans d'expérience sur ce problème, des milliers de conversations avec des utilisateurs, les contributions de personnes du monde entier, deux générations du produit et une liste assez longue de choses que nous ne referions pas de la même façon.

Pendant que nous travaillons sur la v3, je veux documenter davantage tout cela publiquement. Il y a un nombre surprenant de problèmes difficiles derrière quelque chose qui paraît assez simple vu de l'extérieur, surtout quand on commence à réfléchir sérieusement aux relations, aux rappels, à la personnalisation et à la façon de représenter dans une base de données quelque chose d'aussi désordonné qu'une vie humaine. J'écrirai sur ces problèmes, mais aussi sur les décisions techniques et de design que nous prenons, et sur les choses que nous essayons et qui ne fonctionnent pas.

C'est de cela que parlera Building Monica. Je ne sais pas à quelle fréquence je publierai un article, et je n'ai pas envie d'inventer un rythme de publication juste pour en avoir un. J'écrirai quand nous aurons quelque chose d'intéressant à raconter.

En 2017, j'ai construit Monica en fonction de ce que je comprenais du problème à l'époque. Presque dix ans plus tard, je comprends ce problème très différemment. C'est pour cela que nous le reconstruisons.

Cela fait un moment que nous n'avons pas donné de vraies nouvelles de Monica.

Alexis et moi réfléchissons à une nouvelle version depuis très longtemps. Plus longtemps que prévu, évidemment. Reconstruire une application de zéro quand on a un emploi à plein temps, une famille et une vie en dehors de Monica prend un peu de temps, il faut croire.

Mais aujourd'hui, nous pouvons enfin le dire : nous lancerons la nouvelle version de Monica avant la fin de 2026.

Cette nouvelle version, c'est la Monica que nous voulions construire depuis des années. Elle sera plus rapide, plus souple, plus simple à utiliser, et bâtie sur des fondations bien plus solides.

Monica vous aidera toujours à vous souvenir des personnes qui comptent pour vous. Elle restera privée. Elle restera open source. Et vous pourrez toujours l'installer gratuitement sur votre propre serveur.

Nous sommes incroyablement enthousiastes. Monica fait partie de nos vies depuis presque dix ans, et nous avons le sentiment d'ouvrir un tout nouveau chapitre pour le projet.

Il reste beaucoup de travail.

Mais ça arrive. Pour de vrai cette fois.

Merci pour votre patience, vos messages et votre soutien pendant toutes ces années. Nous avons hâte de vous montrer ce que nous avons construit.

Nous sommes ravis d'annoncer qu'après 18 mois d'un travail acharné, notre nouvelle version, nom de code Chandler, est désormais disponible en bêta : https://beta.monicahq.com

Monica est née il y a 7 ans avec l'objectif d'être un CRM personnel. Cette nouvelle version parle de documenter votre vie, y compris ce que font vos contacts, mais pas seulement.

Que signifie « bêta » ? C'est comme avoir une bande de petits bugs espiègles cachés dans notre logiciel, qui jouent à cache-cache avec nous. Nous sommes à peu près sûrs qu'ils sont là, mais nous n'avons aucune idée desquels ni d'où ils se cachent. Nous avons donc besoin de toutes les âmes courageuses pour rejoindre notre escouade de chasse aux bugs et nous aider à les débusquer avant la sortie publique.

Chandler est une réinvention complète de Monica, repensée de fond en comble. Nous avons éliminé l'importante dette technique accumulée au fil des ans et ajouté ou amélioré de nombreuses fonctionnalités. Bien que nous n'ayons fait aucune promotion, beaucoup d'utilisateurs ont déjà testé Chandler et trouvé des bugs que nous avons corrigés, mais nous n'avons pas testé ce logiciel à grande échelle. Alors s'il vous plaît, créez un compte et amusez-vous.

La version disponible sur le serveur de bêta peut être considérée comme stable. Nous ne réinitialiserons pas la base de données. Nous sauvegarderons vos données quotidiennement et nous les conserverons lors du lancement officiel de la version finale.

Chandler comporte quelques limites :

• Vous ne pouvez pas utiliser vos identifiants Monica actuels,
• Vous ne pouvez pas importer vos données,
• Aucun import de masse de contacts n'est disponible,
• Nous n'avons pas encore d'API.

Nous avons de nombreuses nouveautés, une nouvelle mise en page et le très demandé mode sombre.

Sur un plan personnel, la fonctionnalité dont je suis le plus fier est la possibilité de tout personnaliser ou presque dans Chandler : de la mise en page aux modules que vous pouvez activer, jusqu'aux données que vous pouvez consigner sur votre vie.

Chandler reste open source et peut être installé gratuitement sur votre serveur, si vous savez utiliser Docker ou la ligne de commande. Vous pouvez toujours modifier le code si vous le souhaitez. Monica est, et restera toujours, open source. C'est la voie.

Pour l'instant, Monica est gratuite sur notre instance hébergée (https://beta.monicahq.com), mais nous appliquerons les mêmes tarifs que la version actuelle dès que nous considérerons le produit comme stable.

Je suis incroyablement fier de ce que nous avons accompli en huit ans. À l'époque, j'avais peur de rendre mon code public parce que je le savais de piètre qualité. Curieusement, cela n'a semblé déranger personne. Aujourd'hui, notre code est toujours ouvert au public et nous ne craignons plus le jugement. L'application reste une application Laravel, avec VueJS côté client et InertiaJS entre le front et le back. Une pile très simple. Nous nous efforçons de garder notre code aussi simple que possible pour faciliter la maintenance, l'évolution et le recrutement de développeurs pour nous aider.

Nous migrerons bientôt notre image Docker officielle vers Chandler. Cette image a été téléchargée plus de 25 millions de fois, ce qui nous rend humbles.

Au nom de toute l'équipe Monica, merci de nous être restés fidèles tout ce temps. « Toute l'équipe Monica », ce sont en réalité deux amis, Alexis et moi, vraiment passionnés par l'idée de proposer des outils sympas pour améliorer la vie des gens. Monica reste un projet parallèle pour nous, nous avons des emplois à plein temps « à côté ». Pendant que certains jouent à des jeux vidéo ou regardent Netflix, nous « jouons » dans le code de Monica. Et nous adorons ça.

Alexis et moi (Regis) travaillons depuis quelques mois (depuis janvier 2022, en fait) sur une toute nouvelle version de Monica. La première véritable version majeure depuis notre lancement il y a quelques années.

Je suis très tenté de parler d'une version « plus rapide, plus moderne, meilleure », parce que c'est le cas, mais je suis mauvais en marketing, alors je dirai simplement que c'est une nouvelle version et je répondrai ci-dessous aux questions que vous pourriez vous poser.

Qu'entendez-vous par nouvelle version ?

Une réécriture complète de Monica, à partir de zéro.

Vous êtes fous ?

Oui, mais aussi : le code de Monica est devenu ancien. Ancien au sens où il a 7 ans et où des centaines de contributeurs y ont touché. Certains concepts du code ont été laissés passer, soit parce que nous ne savions pas faire mieux à l'époque, soit parce que nous ne voulions pas froisser des contributeurs, et nous n'en voulons plus. Le projet a beaucoup trop de dépendances, et maintenir le code est devenu plus difficile qu'avant. Changer quelque chose est plus risqué et prend plus de temps. Nous avons aussi vu comment les gens utilisent Monica, ce qu'ils veulent en faire, et le code actuel nous limite beaucoup trop pour prendre en charge ces usages. Enfin, Monica reste un projet parallèle pour nous. Nous en sommes extrêmement passionnés et nous voulons aussi prendre du plaisir à le construire. Or la version actuelle n'était pas si amusante.

Qu'entendez-vous par réécriture ?

Nous sommes partis d'un code vide, et nous avons construit à partir de là. Avant, c'était une application Laravel (donc PHP), avec des vues Blade et un peu de Vue par endroits. Maintenant, c'est toujours une application Laravel (donc toujours PHP), entièrement en Vue 3. Nous avons beaucoup simplifié, rendu certaines choses plus souples et donc un peu plus complexes, mais nous pensons pouvoir porter l'avenir de Monica avec.

Cela signifie aussi que nous avons une toute nouvelle structure de données, portée par un nouveau schéma de base de données.

La nouvelle version s'appellera-t-elle Monica ?

Pour l'instant, le nom de code de la nouvelle Monica est Chandler. Nous ne le garderons pas : le nom officiel de la nouvelle Monica sera Monica. Par souci de clarté, nous appellerons la nouvelle version Chandler dans la suite de cet article.

Vous choisissez PHP malgré \<insérez un nouveau langage ou framework> ?

PHP est un excellent langage. Nous ne sommes plus à l'époque de PHP 4 ou 5. C'est aussi un langage très simple, ce qui veut dire que beaucoup de gens dans le monde lisent et comprennent PHP. Choisir PHP, c'est rendre la contribution plus facile, le débogage plus facile, la maintenance plus facile, et il nous sera plus facile de trouver de l'aide si le besoin s'en fait sentir. Enfin, l'écosystème PHP est formidable, avec Laravel qui offre l'une des meilleures expériences de développement que je connaisse.

Quelles fonctionnalités contiendra Chandler ?

Au lancement, nous voulons couvrir 100 % (ou presque) des fonctionnalités de Monica v1. Même à périmètre égal, nous voulions soit les simplifier (les tâches, par exemple), soit les rendre plus robustes (les rappels, notamment).

Une fois cela fait, nous avons tellement d'idées sur ce que Monica devrait devenir que c'en est vertigineux. À l'origine, Monica est né comme le premier CRM personnel (ou PRM, gestionnaire de relations personnelles). Nous l'avons donc présenté ainsi. Mais après des années de travail, de discussions et de lecture des milliers d'emails que vous nous avez envoyés, nous avons compris que Monica est surtout une façon de documenter votre vie, quoi que cela signifie pour vous. Monica parlera donc de documenter votre vie, et de vous donner des outils pour le faire à votre manière.

On lit partout qu'un produit doit avoir un point de vue et une forte personnalité, pour que les gens l'utilisent comme vous l'entendez. C'était la direction de la v1. Nous voulons maintenant changer cela. Nous voulons que chacun utilise et configure Monica comme il l'entend. Qui sommes-nous pour vous dire que vous ne devriez utiliser que 3 pronoms pour vos contacts, ou pour décider des types de relations qui existent chez vous ? Chandler sera entièrement personnalisable, de ce que vous voyez dans l'interface au type de données que vous pouvez saisir. Les gens du marketing diraient « Chandler, c'est vous », et c'est vrai, en un sens. L'inconvénient : d'un point de vue technique, c'est plus difficile à gérer, mais cela nous regarde.

Quand sera-t-elle prête ? Puis-je l'essayer ?

Elle sera prête quand elle sera prête. Rappelez-vous : nous n'y travaillons pas à plein temps, pas du tout. Alexis et moi avons des emplois exigeants, des familles, des amis, et Monica (et OfficeLife, aussi).

CELA DIT.

Nous avons déjà beaucoup avancé. Des fonctionnalités importantes que vous connaissez et appréciez manquent encore à la nouvelle version : les événements de vie, les activités, les cadeaux et CalDAV/CardDAV, pour n'en citer que quelques-unes. Les événements de vie, en particulier, représentent un gros morceau, car nous voulons repenser complètement le concept et le rendre vraiment utile. Et, gros « et », nous n'avons pas encore d'API. Comme il s'agit d'un nouveau code, nous ne pouvons pas simplement copier vos contacts de la v1 et espérer les voir apparaître dans la v2. Si nous sortions quelque chose maintenant, vous ne pourriez pas importer vos données. Et cela nous semble problématique.

CELA ÉTANT.

Nous avons quand même besoin de testeurs pour nous aider à trouver des bugs, même si nous ne faisons pas de bugs ici (lol). Nous avons besoin de gens pour corriger les fautes dans la documentation. Ce que nous pourrions faire, c'est lancer Chandler dans un état très alpha, gratuit pour tous tant qu'il ne sera pas sorti de l'alpha.

Est-ce toujours open source ? Puis-je l'utiliser gratuitement ?

Oui, c'est toujours open source, avec la même licence qu'avant. Monica est donc gratuite, bien sûr, sauf si vous utilisez la version que nous hébergeons, qui finira par coûter quelque chose, comme la version actuelle. Oui, vous pouvez l'installer où vous voulez, sur votre propre serveur. Comme Chandler n'est pas le même code, nous n'avons pas encore l'écosystème riche d'avant ni toutes ces façons de l'installer partout, mais nous y viendrons. Oui, vous pouvez toujours contribuer au code, corriger des bugs, ajouter des fonctionnalités, même si nous nous réservons le droit de refuser vos pull requests si nous estimons ne pas vouloir prendre en charge ce que vous proposez.

Quel avenir pour Monica v1 ?

Nous soutiendrons la v1 jusqu'à ce que Chandler sorte de l'alpha et de la bêta. Elle sera ensuite dépréciée, mais celles et ceux qui l'hébergent pourront continuer à l'utiliser s'ils le souhaitent. La v1 que nous hébergeons nous-mêmes ne sera plus maintenue après cela.

Peut-on déjà contribuer au code ?

Le dépôt est déjà disponible sur GitHub, mais nous sommes loin d'être aussi matures que le dépôt principal actuel. Nous ne sommes donc pas encore prêts à accueillir les contributions de tout le monde, car les choses changent presque chaque jour, mais si cela vous convient, allez-y.

Et ensuite ?

Merci d'abord d'avoir lu cet article jusqu'au bout. Nous sommes extrêmement reconnaissants envers notre communauté et sa passion pour ce petit outil que nous prenons plaisir à construire. Alexis et moi restons très motivés, et nous vous remercions de le porter avec nous. Nous vous tiendrons au courant.

Aujourd'hui, nous utilisons Stripe pour gérer nos abonnements. Autant nous adorons Stripe du point de vue d'un développeur, autant la gestion des taxes dans le monde entier est un vrai casse-tête, surtout en fin d'exercice comptable. Notre comptable nous déteste. Nous devons passer à un autre prestataire de paiement qui traitera correctement toutes ces taxes. Ce prestataire s'appelle Paddle.

Il y a une autre raison à ce changement d'approche. Monica est avant tout un produit open source. Nous avons une immense communauté. Beaucoup d'entre vous hébergent Monica sur leurs serveurs. Comme nous hébergeons aussi le produit nous-mêmes pour le monétiser, nous avons jusqu'ici inclus tout le code nécessaire à la gestion des abonnements dans le code principal. Cela représente beaucoup de code. Nous gérons la souscription, la modification et la suppression d'un abonnement, avec toutes les permissions autour, et ainsi de suite. Ce n'est pas idéal.

Nous avons décidé de retirer tout le code de facturation du code principal et de créer un nouveau portail, appelé portail d'abonnement, pour gérer vos abonnements Monica. Vous devrez créer un compte sur ce site et acheter une clé de licence à coller dans votre compte Monica. Rien d'autre n'est nécessaire.

Si vous avez actuellement un abonnement, nous vous permettrons de basculer facilement votre compte vers le nouveau. Des instructions détaillées suivront par email pour chacun d'entre vous.

Nous prévoyons de passer à ce nouveau portail client dans les prochaines semaines.

Cela faisait longtemps. Un an, en fait, depuis le dernier article. Dans celui-ci, nous parlerons de la version 2.16 que nous venons de publier, de ce qui s'est passé en 2019 et de la suite pour Monica.

La version 2.16 contient 226 changements, pour la plupart des corrections de bugs ou des améliorations du code. Mais elle apporte aussi son lot de nouveautés, décrites ci-dessous.

Une nouvelle façon d'ajouter des activités

Vous pouvez désormais ajouter des activités sur place, au lieu de passer par une nouvelle page. Comme pour les appels, vous pouvez indiquer les émotions ressenties pendant une activité.

Une page de réglages API améliorée

L'essentiel de ce que vous faites avec Monica peut être réalisé via l'API. Il est extrêmement important pour nous que chacun puisse manipuler ses données à sa guise. Il était donc temps de soigner un peu la page de réglages de l'API.

Nous avons également ajouté de nombreuses méthodes à l'API pour poursuivre notre ouverture aux autres systèmes.

Beaucoup de changements en coulisses

Nous avons aussi complètement changé la façon dont les données sont stockées, en ajoutant des clés étrangères à chaque table de la base. Cela n'a aucun impact sur l'expérience des utilisateurs, mais c'est majeur pour nous, développeurs, car cela nous donne plus de contrôle et de souplesse. Ce fut un énorme changement et les pull requests ont mis près de 11 mois à être fusionnées.

Nous avons également revu de fond en comble le processus d'export des données, qui devrait fonctionner parfaitement désormais (ou, comme on dit : 60 % du temps, ça marche à tous les coups).

Que s'est-il passé en 2019 ?

En 2019, nous avons un peu ralenti sur le nombre de versions annuelles. L'activité sur ce blog a par ailleurs été inexistante. Cela n'a pourtant pas affecté le nombre d'inscriptions, ni le nombre de téléchargements, ni l'affection des internautes pour ce projet.

En clair, Monica n'a jamais été aussi solide. Notre image docker officielle approche les 5 millions de téléchargements. Nous avons des dizaines de milliers d'utilisateurs sur notre version hébergée. Monica continue de surgir sur Hacker News et notre suivi des tickets sur GitHub est plus actif que jamais. Nous avons aussi fusionné 875 pull requests en 2019.

Alors pourquoi ce silence ? Principalement à cause de moi (Regis). J'ai lancé Monica il y a maintenant presque quatre ans. Avoir un projet populaire est très amusant, mais cela demande aussi beaucoup d'énergie et de motivation. D'autant que Monica reste un projet parallèle pour Alexis comme pour moi. Cette année, Monica est devenue trop lourde à porter, et c'est en général moi qui écris sur ce blog ou sur les réseaux sociaux. J'ai fait un burnout de projet parallèle, si l'on veut. Alexis a pris beaucoup de travail sur ses épaules pour maintenir et faire évoluer le produit, mais je n'ai pas pu y travailler autant qu'avant, ni publier de nouvelles. J'avais besoin de faire autre chose, de me vider la tête et de revenir seulement quand je serais prêt. Je le suis maintenant, et je suis plus que motivé pour m'y remettre et prendre du plaisir à nouveau.

Monica en 2020

Il y a quatre ans, Monica était l'un des premiers CRM personnels populaires. Aujourd'hui, la concurrence est plus nombreuse que jamais (une douzaine, à mon dernier décompte). Mais je crois que nous avons un avantage que nos concurrents ne peuvent pas nous prendre : nous sommes open source, nous n'avons pas ou presque pas de charges ni de coûts, et nous ne sommes pas avides. Tout ce que nous faisons, nous le faisons d'abord pour la communauté. Plus il existe d'instances de Monica dans la nature, plus nous sommes heureux : cela signifie que nous n'avons aucun contrôle sur les données de nos utilisateurs.

En 2020 :

• Nous voulons poursuivre notre travail d'ouverture et de transparence. Cela signifie plus de façons d'exporter ou d'importer des données dans un format standard.
• Nous voulons proposer des webhooks pour que des systèmes externes soient informés quand des données changent dans votre compte (si vous le souhaitez, bien sûr).
• Je pense que Monica est aujourd'hui le meilleur outil pour documenter vos contacts personnels. Vous pouvez consigner à peu près tout. Maintenant que nous avons des fondations très solides, il est temps d'aller plus loin. Il est temps de vous laisser faire davantage avec vos contacts, en créant des groupes (ou des familles), des événements, des opportunités, etc. Nous nous concentrerons sur des notions simples, ajoutées progressivement à la plateforme, qui vous offriront le maximum de souplesse.

Monica est un outil pour vous. Continuez à partager vos idées, continuez à m'écrire pour dire ce que nous devrions faire ensuite. Nous sommes là pour vous.

Et bonne année 😀

Après plus d'un mois de travail, je suis heureux d'annoncer la nouvelle version de Monica, avec l'envoi de photos, une sécurité renforcée, une meilleure gestion des appels, la météo, l'introduction des émotions et bien d'autres améliorations.

Envoi de photos

Vous pouvez désormais envoyer des photos sur la page de profil d'un contact. Le nombre de photos que vous pouvez stocker dépend de la limite de stockage de votre compte, qui est de 512 Mo sur https://monicahq.com (et configurable par instance). La possibilité d'envoyer des photos ouvre beaucoup de perspectives pour la suite.

Codes de récupération

La sécurité est essentielle, surtout dans un outil comme Monica qui conserve de nombreux détails intimes. Monica prend déjà en charge l'authentification à deux facteurs (2FA) et U2F pour vous aider à sécuriser votre compte. À partir de Monica 2.11, vous pouvez générer des codes de récupération pour débloquer votre compte si vous perdez la possibilité de vous connecter avec la 2FA. Attention toutefois : comme ces codes donnent accès à votre compte, conservez-les dans un endroit très sûr.

Appels téléphoniques

Les appels ont reçu beaucoup d'attention dans cette version. D'abord, nous avons repensé le parcours pour les enregistrer. Ensuite, nous avons (enfin) ajouté la possibilité de modifier un appel passé. Et en prime, vous pouvez maintenant indiquer qui a initié l'appel.

Émotions

Ne serait-il pas formidable de pouvoir dire, très précisément, ce que vous avez ressenti quand quelque chose est arrivé ? Monica 2.11 introduit la notion d'émotions, fondée sur les travaux du Dr Phillip Shaver. Dans ses travaux, les émotions sont classées en 3 grandes catégories :

• les émotions primaires (amour, joie, surprise, colère, tristesse et peur),
• les émotions secondaires (amour -> affection, désir, manque),
• les émotions tertiaires (amour -> affection -> adoration, amour, tendresse, attirance).

Nous avons intégré ces notions dans Monica, en commençant par les appels. Un nouveau menu déroulant vous laisse choisir autant d'émotions que vous le souhaitez, afin de représenter très précisément ce que vous avez ressenti pendant un appel. Nous prévoyons d'ajouter les émotions à d'autres éléments clés, comme les activités.

Météo

Quand vous parlez avec un ami qui vit dans une autre région, il y a de fortes chances que vous finissiez par parler de la météo. Monica vous aide ici, en affichant la météo actuelle du lieu où vit votre ami. Cette information provient de la première adresse trouvée sur la page de profil du contact. Autrement dit, si aucune adresse n'est renseignée, aucune information météo ne sera affichée.

Les données météo viennent de Darksky et sont rafraîchies toutes les 6 heures. La seule information transmise à Darksky est la latitude et la longitude, rien d'autre. Pour les propriétaires d'instance, Darksky propose un forfait gratuit de 1 000 appels par jour, ce qui devrait largement suffire.

Coordonnées GPS

À propos de latitude et de longitude, il nous fallait un mécanisme pour obtenir ces deux informations pour chaque adresse saisie dans Monica si nous voulions afficher la météo. Monica 2.11 sait désormais géocoder automatiquement n'importe quelle adresse pour en trouver les coordonnées.

Quand vous saisissez une adresse, et si le service est configuré au niveau de votre instance, nous essaierons de la géocoder automatiquement, sauf si vous fournissez vous-même la latitude et la longitude du lieu.

Le géocodage est assuré par LocationIQ, une entreprise indépendante et remarquable qui propose un forfait gratuit très généreux de 10 000 appels par jour. Nous ne partageons avec LocationIQ rien d'autre que l'adresse, afin d'en récupérer les coordonnées.

Tâches

Sur votre tableau de bord, vous pouvez désormais ajouter des tâches qui ne sont liées à aucun contact.

Améliorations

Nous avons beaucoup remanié la façon dont les choses sont écrites en interne, pour poursuivre notre quête d'une plateforme la plus stable possible. Nous avons aussi continué à augmenter la couverture de code (c'est-à-dire la part de notre code réellement testée automatiquement). Nous en sommes à 66 % sur l'ensemble du code.

Nous espérons que vous aimerez la 2.11 autant que nous.

Je viens de retirer les applications mobiles de l'App Store comme du Play Store. Le seul moyen de les obtenir est désormais de les compiler depuis le dépôt GitHub.

Theo a fait un travail formidable sur la première version de ces applications, mais leur développement s'est arrêté au début de l'été alors que celui de Monica, la plateforme, a continué. Nous sommes maintenant dans une situation où l'application mobile n'est plus au niveau de la plateforme et, pire, nous allons casser dans l'API des choses que l'application ne saura pas gérer.

Je reste convaincu que la croissance et l'adoption de Monica passeront par une application mobile.

J'aimerais promettre de belles choses et annoncer une nouvelle application dans 2 mois, mais en réalité je ne sais pas combien de temps cela prendra. Comme Monica en est encore au stade du projet parallèle, cela peut prendre 6 mois ou 2 ans. Mais un jour nous aurons une excellente application mobile, aussi bonne que la version web (voire meilleure).

Merci de votre patience.