J'ai discuté récemment avec un entrepreneur expérimenté qui souhaite créer un logiciel pour automatiser une partie de ses activités, et répondre ainsi de façon plus réactive à ses clients.
Dans son esprit, l'automatisation passe par le stockage de données de référence (taux, indices boursiers, ...) qui évoluent chaque jour. Il faut donc une base de données. Il a lu que Postgresql était un système de gestion de base de données très performant (c'est vrai).
Alors pour son projet, il part à la recherche d'un expert Postgresql.
Est-ce réellement ce profil dont il a besoin ?
Non, pas du tout.
D'ailleurs, le volume des données à gérer restera modeste. Le nombre de requêtes également. La difficulté technique du projet n'est pas du tout sur la base de données. Par contre, il y a une belle complexité algorithmique dans son projet, ainsi qu'une difficulté pour importer et valider des données depuis des sites externes.
En confiant le projet à un expert Postgresql, les chances de succès sont minces. L’expert va essayer de tout faire avec Postgresql (normal, c'est sa spécialité). C’est l’outil qui va piloter le projet. On fera ce qui est possible avec l’outil, au lieu de prioriser les fonctions qui ont le plus de valeurs pour les utilisateurs.
Artisans et consultants
En démarrant le projet sous l'angle du choix technique, vous allez avoir tendance à travailler avec des "artisans".
Ce n'est pas du tout péjoratif. L'artisan, c'est le savoir faire. L'expert réellement bon sur un outil qu'il utilise depuis longtemps. L'artisan est un passionné. Il ne compte pas ses heures. Il vous parlera avec enthousiasme, et vous convaincra sans mal qu'avec cette technologie on peut tout faire (y compris votre projet).
Mais pour le début du projet, je constate qu’il est plus facile de travailler avec des "consultants". Ce terme a lui aussi un côté un peu péjoratif !
Le consultant a une vision plus entrepreunariale de votre projet. Il va chercher à bien le comprendre, et pas seulement sur ses aspects techniques : qui sont les utilisateurs ? Qu'est-ce qui va changer pour eux ? Quelle valeur vont-ils retirer du logiciel ? Comment allez-vous gagner de l'argent (ou faire des économies) avec ça ? Quel est votre marché ?
Le consultant aborde un projet avec un moindre niveau de détail que l'artisan. Il va réfléchir aux concepts manipulés par l'application, aux flux d'informations échangés. Le choix technique se fera dans un second temps. Il n’a pas de religion toute faîte sur tel langage de programmation ou tel framework :
- Plutôt que de partir sur un développement spécifique, est-il possible d’utiliser un outil no-code (comme AirTable, WordPress ou Bubble.io) ?
- Existe-t-il des des services externes (API) prêts à l'emploi qui évitent de re-développer ce que d'autres font déjà très bien ?
- Peut-on ré-utiliser des projets open-source qui implémentent des fonctionnalités très proches de celles que l’on recherche ?
La limite de la démarche est que le diable se cache dans les détails. Avec une vision trop théorique, les rappels à la réalité peuvent être brutaux. Et le code développé ne va pas beaucoup plus loin que la version 1 (voire s'arrête au powerpoint).
C'est à ce moment que les atouts de l'artisan seront précieux. Après cette période de "défrichage", ou "d'exploration", l’artisan dispose d'une vision assez précise de ce qu'il faut coder. Il est davantage lucide sur les risques et les points techniques délicats qui l'attendent.
Un projet informatique, c’est un peu comme franchir une colline.
Dans la pente montante, on avance sans trop savoir ce qui nous attend. Mais arrivé en haut, on dispose d'une vision panoramique de ce qu'il reste à faire et des pièges qui nous attendent pour arriver à destination.
Dans la montée, vous serez probablement mieux accompagné par un profil de "consultant". En revanche, un "artisan" sera plus à l'aise dans la descente.
