Contrairement à tous les articles générés par IA qui pullulent partout sur Internet, vous ne trouverez pas ici un énième historique du NoCode ni une énième définition, je pars du principe que si vous êtes ici c’est que vous avez déjà entendu le terme et qu’on vous a déjà fait tout le laïus de base, que ça va vous aider, que ça peut sauver votre vie et si on écoute tous les commerciaux qui en parlent, cela pourrait aller jusqu’à faire le café ou même éradiquer la maladie de la surface de la planète.
Mais si vous n’avez jamais entendu le terme je vous invite à creuser un peu le sujet avant de lire la suite de cet article. Vous pouvez déjà vous rendre sur l’article Wikipedia qui est plutôt complet ou sur n’importe quelle page de n’importe blog orienté NoCode qui en donne une définition, c’est d’ailleurs toujours la même, à croire qu’ils ont généré leurs articles par IA (et vu le reste des contenus de ces blogs c’est très surement le cas). Vous découvrirez sans doute que vous avez déjà utilisé un outil identifié NoCode tel que WordPress ou tout autre outil plus récent développé ces dix dernières années.
Je ne vais pas non plus vous faire une liste à la Prévert de la foultitude d’outils NoCode disponibles sur le marché aujourd’hui, j’ai l’impression qu’il y en a dix nouveaux tous les jours, voire toutes les heures, et je ne tiens pas particulièrement à en promouvoir un plus qu’un autre pour le moment même si j’en utilise surtout un en particulier. J’ai parfaitement conscience que cela risque de biaiser mon approche du sujet mais je ferai tout mon possible pour conserver une certaine objectivité.
Je ne vais surtout pas vous affirmer que n’importe qui peut prendre en main n’importe quel outil NoCode du jour au lendemain, ce serait vous mentir et je ne parviendrai qu’à vous en dégoûter. Je peux par contre vous raconter mon parcours personnel, les connaissances sur lesquelles j’ai pu m’appuyer pour monter en compétences, les applications que j’ai conçues et vous apporter une analyse très personnelle du sujet, on pourra discuter de tout ça autour d’un café en visioconférence, vous trouverez un lien pour prendre rendez-vous avec moi à la fin de l’article, tout en bas.
Comment je suis arrivée dans le petit monde du NoCode ?
La réponse va vous surprendre, mais c’est la même que celle que je donne à la question « Comment es-tu arrivée dans la politique ? » qu’on me pose quand je raconte ma première vie. Je suis arrivée dans le NoCode complètement par hasard. Je ne savais pas que j’arrivais dans le NoCode quand j’y suis arrivée, d’ailleurs le terme NoCode, bien qu’il correspondait parfaitement au logiciel qu’il éditait, n’était pas vraiment revendiqué par mon futur employeur à l’époque de mon embauche, en 2021. Un ami m’avait transmis une annonce à laquelle mon profil ne correspondait pas mais il me connaissait bien, il était persuadé qu’après une rapide formation je pourrai assumer le travail demandé, il a donc poussé ma candidature et malgré ses réticences, mon futur employeur a fini par me prendre à l’essai. Cet ami est sans doute passé à côté d’une brillante carrière de RH. On ne saura jamais.
Le paragraphe suivant pourra être interprété de deux manières différentes, il s’agira peut-être pour vous d’un message d’autopromotion, et je ne peux pas nier cette interprétation, mais ma volonté est plutôt d’évacuer rapidement tel un pansement qu’on arrache un méchant syndrome de l’imposteur que je traîne comme un boulet depuis le début de ma carrière.
Je ne suis pas développeuse. Je n’ai jamais appris à coder. Le code le plus abouti que j’ai pu faire c’était des formules sur Excel, un peu de Markdown ou quelques balises HTML, à la marge. Il m’a fallu 5 mois d’apprentissage à temps plein sur deux projets pour véritablement prendre en main l’outil NoCode développé par mon ex employeur ainsi que la plupart des mécaniques annexes utiles au développement d’applications sur l’outil en question. Je disposais cependant d’une base solide.
Ma formation initiale en littérature m’a apporté une grande capacité à la description et à la synthèse. Ma licence professionnelle de management, qui intégrait notamment l’utilisation très poussée d’Excel et d’Access, m’a appris à structurer ma pensée et à étudier, anticiper et comprendre les interactions entre les parties prenantes dans la prise de décision. Et puis je peux justifier de plusieurs expériences dans l’élaboration de cahiers des charges en vue du développement d’outils métiers, d’une grosse appétence pour les outils numériques et d’un intérêt certain pour les processus décisionnels que j’aime beaucoup décortiquer afin de comprendre les dynamiques organisationnelles sur lesquelles ils reposent. Sur ce dernier point, vous avez sans doute déjà vu passer mes vidéos d’analyses de statuts.
Donc quand on m’a mise devant un outil qui rassemblait de la gestion de bases de données relationnelles adossées à des processus avec un système basé sur des opérations comme celles que j’ai déjà maintes fois appliquées, jusque dans le cadre de mes loisirs, dans Excel, j’ai vite été comme un poisson dans l’eau.
Tout syndrome de l’imposteur évacué, je maintiens que n’importe qui ne peut pas s’improviser expert NoCode du jour au lendemain.
Je ne dis pas que ce n’est pas possible d’apprendre à utiliser les outils ou de monter des applications sans apprendre à coder, j’en suis la preuve.
Mais j’affirme que ce n’est pas possible de les utiliser sans passer par une formation, au moins pour comprendre les bases fondamentales de l’objet de votre travail, au mieux pour connaître les trucs à faire ou ne pas faire et éviter de faire n’importe quoi n’importe comment, j’en suis la preuve.
Pourquoi choisir un outil NoCode ?
Il y a plusieurs cas de figure qui amènent des gens à aller vers du NoCode mais, c’est comme pour tout dans la vie, on n’y vient pas forcément pour de bonnes raisons. J’ai vu passer, il y a quelques temps maintenant, une vidéo Underscore au titre très accrocheur, qui a été changé depuis pour un titre beaucoup plus pertinent, « Pourquoi le NoCode est un piège pour les startups ? ». Dans cette vidéo, on entend une série d’expériences foireuses du NoCode. Toutes ces expériences sont très similaires. Dans tous les cas, il s’agit de startups qui esquissent un projet, qui le vendent ou parviennent à trouver des investisseurs pour le développer mais qui souhaitent faire l’économie d’un développement à proprement parler et qui, prises par le temps ou limitées par un budget très serré, choisissent de monter leur application en utilisant des outils NoCode souvent peu adaptés, souvent en suivant des recommandations d’utilisateurs convaincus mais sans aucune étude de marché préalable (pas le temps, pas les moyens) et sans aucun recul (pas le temps, pas les moyens).
Je pense que la conclusion, qui est le titre de la vidéo, est bonne. Le NoCode est un piège pour les startups, et je ne comprends même pas pourquoi, à la base, une startup qui proposerait une idée d’application originale et qui trouverait le client pour la payer ou le financement pour la développer, choisirait de faire l’économie d’un développeur ou d’un concepteur d’application professionnel et s’orienterait, sans aucune formation, vers un développement à l’arrache, sans aucune formation, sur n’importe quel outil NoCode ou LowCode, sans aucune formation1.
Pour moi, cette approche revient à dire qu’on a une super idée de livre, qu’on le vend à un potentiel lecteur (le client) ou a un éditeur (l’investisseur) et qu’on ne prend pas le temps nécessaire pour apprendre à écrire.
Cela fait maintenant 4 ans que je conçois des applications sur un outil NoCode, et en 4 ans je n’ai encore jamais rencontré de startup qui a une idée et qui cherche un concepteur d’application pour mettre son idée à exécution. Tous les projets sur lesquels j’ai travaillé, et j’ai travaillé sur une centaine de projets, étaient des projets qui visaient à répondre à un besoin métier bien déterminé afin de simplifier le quotidien du métier ou de remplacer une autre application pas assez complète ou pas assez adaptée au besoin du métier. Je ne dis pas que mon travail ne s’y prêterait pas ou que je ne suis pas capable de travailler sur une création d’application qui serait le principal objet d’une startup, je dis simplement que personne n’est venu me demander un avis professionnel sur la possibilité d’utiliser l’outil que je maitrise pour adresser un besoin applicatif spécifique nouveau sans connaitre l’utilisateur final. C’est peut-être lié à un manque de notoriété de l’outil, c’est peut-être lié à la stratégie commerciale de l’éditeur qui ne souhaite peut-être pas aller dans cette direction, donc ce n’est probablement pas un bon argument. Peut-être que ça changera après cet article, qui sait.
J’ai entendu la notion « développeur rockstar », mais ce n’est pas vraiment un terme que j’appliquerais à la personne interrogée sur le plateau de l’émission Underscore. L’homme a imaginé un concept d’application puis trouvé un client qui lui a mis une deadline impossible à tenir. J’imagine que c’est par fierté qu’il a répondu qu’il tiendrait la deadline intenable. C’est sans aucun doute la panique qui l’a poussé vers un outil NoCode qu’il utilisait déjà sans aucune étude de marché préalable pour trouver un outil plus adapté.
Son projet n’était pas précis, le client lui a ajouté un tas de demandes qu’il n’avait pas anticipé. Normal. Le projet de base était simpliste mais le métier est, comme toujours, exigeant. Bien que l’outil conçu ait apporté satisfaction à son client pour un premier usage, il ne répondait pas à toutes les demandes qui ont suivi et il a choisi de s’orienter vers du code. Mais avant d’aller vers du code, grâce à toute cette expérience sans code, il a pu préciser le besoin métier et ça lui a permis de développer beaucoup plus vite et mieux l’application qu’il avait vendue au départ.
Moi, la première chose qui me vient à l’esprit après avoir écouté son histoire, c’est l’expression « mettre la charrue avant les bœufs ».
Et, dans la même émission, l’histoire des deux femmes qui ont créé leur application d’hôtellerie est plus ou moins la même, elles vendent un concept à des investisseurs qui les suivent parce que c’est joli sur le papier mais il s’avère qu’elles n’ont développé que l’interface graphique et n’ont pas du tout réfléchi à la faisabilité technique de leur application ni à tout ce qu’il y a derrière la jolie présentation, autrement dit à l’intelligence de l’application.
Une application avec une jolie interface mais sans intelligence, c’est comme un livre dont on aurait que la couverture et aucune page, même blanche, à l’intérieur.
Oui, même un livre avec des pages blanches peut avoir du sens.
Le NoCode n’est pas magique
La promesse du NoCode, c’est effectivement la perspective de faire l’économie d’une équipe de développeurs chevronnés, mais ça ne saurait s’appliquer en toutes circonstances pour toutes les idées d’applications. Il y a des cas où les applications existent déjà, on parlera d’applications « sur étagère ». Ces applications sont développées pour répondre à un besoin spécifique documenté par les métiers.
Par exemple, il sera difficile et même déconseillé de tenter de créer une application de gestion de paie avec des outils NoCode pour une raison plutôt simple. Au-delà du fait que de telles applications existent aujourd’hui pour des coûts plutôt très compétitifs, le développeur NoCode qui développerait cette application devrait en outre maintenir une veille sur les nombreuses évolutions du code du travail dans le ou les domaines professionnels sur lesquels il intervient. Il devra ensuite appliquer avec rigueur toute modification législative dans son application, au risque de devoir en changer toute la structure. C’est un risque non négligeable qui est déjà assumé par les éditeurs de logiciels de gestion de paie sur étagère qui doivent se donner les moyens d’engager des juristes pour assurer cette veille et sa mise en application.
Je dis cela tout en sachant que le code ne sait pas non plus y répondre correctement en toutes circonstances.
La question, là encore, et finalement dans toutes les circonstances, c’est de savoir qui fait la veille, et donc à quel niveau est l’intelligence. Est-elle au niveau des développeurs ou des nocodeurs ? au niveau du commercial ou du startupeur ? ou encore, et c’est là que je vous emmène, l’intelligence n’est-elle pas, en définitive, au niveau des métiers ?
En revanche, il est beaucoup plus difficile de trouver un outil sur étagère qui permettrait une gestion sur mesure d’une flotte de véhicules professionnels, ou la gestion sur mesure d’un processus de recrutement spécifique à une organisation. Il en existe, bien entendu, mais ces outils ne sont pas sur mesure, ils sont conçus pour répondre à un besoin métier global sur la base de plusieurs retours d’expériences et peuvent difficilement s’adapter aux spécificités de telle ou telle organisation. Je ne compte plus le nombre de fois où je me suis retrouvée en présence d’un métier qui était contraint d’utiliser un outil-sur-étagère-bourré-de-fonctionnalités-inutiles pour faire un travail qui n’en nécessitait que le dixième, et à chaque fois la même problématique se posait : il n’y avait aucun moyen de gérer la ou les exceptions liée(s) à leur organisation, ce qui rendait donc l’outil-sur-étagère-bourré-de-fonctionnalités-inutiles complètement inadapté au besoin du métier.
Ce que j’aime dire à mes clients, c’est que le NoCode permet de gérer les exceptions. Toutes les fois où vous vous dites que vous aimeriez bien que, dans certains cas, le véhicule ne puisse être réservé qu’à certaines heures de la journée ou par certaines personnes plutôt que d’autres, ou que pour certains recrutements, le processus est différent, la candidature ne doit pas suivre le circuit de validation dit « normal ». Ce sont ces exceptions qu’un outil NoCode vous permet de gérer là où une application sur étagère serait complètement inutilisable.
Je ne dis pas que le NoCode permet de remplacer le code, je dis que pour certains projets il est inutile de réinventer la roue, si on connait l’objectif et si les outils à notre disposition le permettent, il est tout à fait possible d’adresser un besoin rapidement et pour un coût moindre sans avoir à recruter une équipe entière de développement pour y parvenir. Reste l’intelligence à y intégrer.
Cette intelligence, j’en suis convaincue, elle se trouve au niveau du métier, et le rôle d’une personne comme moi est de la comprendre, de l’anticiper, pour pouvoir ensuite la traduire dans un langage compréhensible pour la machine.
Le NoCode ne va pas remplacer les métiers ni le code, il permet d’aider les métiers à rationaliser leur activité, à optimiser leur temps, à faciliter leur vie par la mise en commun du développement de technologies réutilisables d’un métier à l’autre. Le NoCode, ce sont en fait des tas d’applications développées par des codeurs qui proposent des services clé en main en direct aux métiers sans passer par la case du packaging (produit sur étagère).
Si les applications NoCode sont trop souvent considérées par les DSI comme leurs pires ennemies, ce n’est pas seulement parce qu’elles posent des problèmes de sécurité des données, puisque les applications NoCode proposent souvent d’héberger les données des utilisateurs sur des serveurs qui leur appartiennent. J’y reviendrai. Mais à cause de cette nouvelle technologie, j’ai le sentiment que les DSI sont brutalement confrontées à une remise en question totale de leur rôle au sein des organisations en étant challengée très violemment sur leur capacité à répondre à des besoins métiers en un temps record.
Les éditeurs de NoCode ne vendent pas une application clé en main, ils vendent un outil permettant au métier de réaliser lui-même l’application clé en main. Mais ils donnent, en plus des clés, tous les outils permettant de modifier à l’envi l’application sans passer par la DSI, donc en limitant les contraintes de temps ou d’argent liée à l’intervention d’une armada de développeurs.
Pourtant, plutôt que de considérer le NoCode comme une cible à abattre, les DSI auraient tout intérêt à s’en servir comme facilitateur entre elles et les métiers.
Ainsi, comme on l’a vu dans cet épisode d’Underscore, le NoCode pourrait permettre de réaliser une ébauche d’application utilisable sur un court à moyen terme pour rendre service rapidement à un métier. Cette ébauche permettrait à l’équipe de développement de comprendre précisément les attentes, les besoins et l’utilité de l’application. Et peut-être, plus tard, si le besoin est toujours présent, si le NoCode ne suffit pas, si l’ambition est de tout développer en interne pour rassurer le métier ou la DSI sur le long terme et ainsi conserver et cultiver l’intelligence de l’entreprise et surtout quand on en aura les moyens humains et financiers, on pourra bien entendu développer l’équivalent de l’application NoCode en interne. Le NoCode pourrait donc être considéré comme une opportunité, une béquille, une solution temporaire ou une aide précieuse pour faire le lien entre la DSI et le métier.
Qui contrôle les données ?
Oui, les éditeurs NoCode hébergent la plupart du temps les données des utilisateurs. Cela pose question quant à la sécurité des données et je suis d’accord pour affirmer que c’est probablement là le principal problème de ces outils. C’est un problème surtout lorsque les outils en question sont édités par des entreprises hors UE pour lesquelles nos règles concernant les données personnelles ont bien du mal à être respectées, surtout lorsqu’il leur est plus intéressant de payer l’amende que de respecter la loi.
<ironie> Et vive le capitalisme. </ironie>
Alors si vous devez vous lancer dans le développement d’une application en NoCode, si j’ai un conseil à vous donner, tachez autant que possible de choisir un éditeur français qui héberge ses données sur des serveurs français ou européens et qui vous permet d’extraire toutes vos données à tout moment de la vie de votre application.
Ils sont peu nombreux, certains d’entre eux sont membres de l’association NoCode France, certains sont référencés sur le site des Pépites Tech, sinon vous pourrez peut-être les croiser dans certains salons professionnels.
Néanmoins, une fois le problème des données évacué, il faut aussi accepter que l’intelligence de votre application, son fonctionnement, ses processus associés et les tâches qu’elle déclenche, tout cela restera difficile à extraire d’une application développée sur un outil ou un autre pour être ensuite réutilisée ailleurs.
En effet, les processus déployés par la multitude d’outils sur le marché ne répondent actuellement à aucune norme. Dans le domaine de l’outil dont je suis devenue experte, il existe une norme, le BPMN, qui permet au métiers et aux développeurs de se comprendre les uns les autres. L’objectif ensuite à atteindre est de produire des applications pour répondre à tous les besoins grâce notamment à un langage, le BPEL, qui n’est qu’une utilisation du XML permettant de décrire des processus étape par étape. Ce « langage » est particulièrement complexe et peu intuitif.
Mais si la norme permet parfois de produire un cahier des charges, le langage en lui même ne permet pas forcément de produire un fichier source qu’on pourrait transposer d’un outil à l’autre. L’outil sur lequel je travaille, comme tous les outils NoCode par ailleurs, ne permet pas non plus à l’utilisateur d’extraire l’intelligence d’une application pour la réutiliser dans un autre outil.
Vous l’aurez donc compris, les DSI le savent très bien et c’est aussi ça qui peut leur faire peur, à partir du moment où vous décidez d’utiliser un outil NoCode plutôt qu’un autre, vous prenez un risque de dépendance technique non négligeable.
Que l’outil soit libre ou propriétaire ne changera pas grand chose à cette difficulté là.
La seule solution si vous tenez absolument à rester propriétaire, indépendant et le seul maitre de l’intelligence de votre application c’est évidemment de développer votre application en interne avec une bonne équipe de développeurs.
C’est le choix que font certaines entreprises, et ces entreprises savent aussi que si le NoCode a ses limites, les développements internes en ont aussi, à commencer par le temps de travail nécessaire pour parvenir à égaler ce qu’un développement sur une application NoCode vous permettrait de réaliser beaucoup plus rapidement.
Quand une équipe entière de développement annonce qu’elle compte répondre à un besoin métier en plusieurs mois, voire plusieurs années, un seul concepteur NoCode peut le faire parfois en quelques semaines, quelques jours ou même quelques heures…
Lorsque vous adressez un besoin urgent, la dépendance technique à l’outil en question peut alors devenir un problème très secondaire.
Peut-on tout faire sans code ?
Mon expérience du NoCode se concentre principalement sur une application comparable à une boite de LEGO™ dans laquelle vous disposez de briques de plein de formes et de couleurs qui peuvent s’assembler pour construire à peu près tout ce qui vous viendrait à l’esprit.
Ainsi, j’ai pu concevoir une application de suivi de la fiscalité du patrimoine pour une communauté d’agglomération. Dans cette application, les métiers saisissent tous les avis fiscaux liés à leur patrimoine, de la taxe foncière à la taxe sur les logements vacants en passant par la taxe d’habitation. Les métiers peuvent ensuite obtenir un bilan et un budget prévisionnel des coûts liés aux taxes sur les patrimoines en quelques clics.
J’ai aussi conçu, pour mon seul usage, une application qui me permet de cataloguer les systèmes et planètes découverts dans No Man Sky.
J’ai conçu, dans le cadre d’une commande client, une application permettant de recevoir, suivre et attribuer des demandes d’intervention des agents municipaux d’une commune.
J’ai aussi conçu, dans le cadre de mon propre engagement politique, une application pour recenser et pré-remplir les formulaires CERFA des candidatures aux élections législatives.
Quand j’ai commencé à travailler sur cette application, ma première idée a été d’adresser l’un après l’autre tous les besoins auxquels j’ai été confrontée tout au long de ma carrière, j’ai donc créé, en à peine quelques jours, une application permettant de gérer une association de l’adhésion à la convocation à l’Assemblée Générale, en passant par les inscriptions aux événements ou le suivi des notes de frais de la dépense à la prise en charge par la comptabilité…
La liste des possibilités offertes par un tel outil, et par tous les autres outils du même genre sur le marché, n’a de limite que votre propre imagination.
Mais, pour que le NoCode se démocratise, à mon avis, il faudrait commencer par arrêter de vouloir s’en servir pour créer des besoins qui n’existent pas et commencer à s’appliquer à répondre aux besoins qui existent. Et des besoins qui existent et auxquels les outils sur étagère ne répondent pas entièrement, il y en a déjà un paquet.
Peut-être d’ailleurs que les outils sur étagère vont progressivement disparaître au profit d’outils sur mesure plus ou moins spécialisés dans un domaine particulier.
Peut-être que les métiers vont progressivement évoluer pour intégrer davantage le développement d’applications métiers, d’algorithmes, de théorisation des processus dédiés à aider des équipes à atteindre des objectifs en réduisant les coûts et le temps passé sur des taches répétitives qui n’ont aucun intérêt.
Peut-être que les applications NoCode existantes aujourd’hui vont progressivement se spécialiser dans un domaine d’activité, c’est d’ailleurs déjà le cas pour certaines d’entre elles. Ainsi, elles s’appliquent à répondre aux besoins spécifiques de leur niche.
Dans le monde dans lequel nous vivons, nous ne pouvons plus faire semblant de croire qu’il est encore possible de vivre sans la technologie. Utilisée de la bonne façon au bon moment, la technologie peut-être un soutien de poids dans la réalisation de vos projets, mais je suis la première à penser que, mal utilisée, elle peut très vite devenir votre pire ennemie.
Je pense que concevoir une application en NoCode sans avoir de besoin métier à adresser c’est comme un corps sans âme, un golem que vous pourrez sans le moindre doute contrôler mais avec lequel vous n’aurez aucune interaction intéressante et qui finira par dépérir si vous ne décidez pas vous même de mettre fin à ses jours.
Je pense aussi que la conception d’applications sur des outils NoCode nécessite des compétences qui ne sont probablement pas celles qu’on imagine au premier abord, mais comme pour tous les métiers, ça s’apprend.
De la même manière qu’on ne s’improvise pas électricien quand on est plombier, on ne saurait s’improviser développeur NoCode quand on est commercial.
Mais je suis maintenant convaincue que les meilleurs potentiels développeurs NoCode sont les métiers eux-mêmes dès lors qu’ils sont en capacité de prendre du recul sur leur profession, d’analyser leur travail, leurs besoins et leurs attentes et de se poser les bonnes questions pour avancer.
Malgré toutes mes expériences de développement d’application en NoCode, je ne me considère pas comme une simple développeuse NoCode. Je suis plutôt l’huile qui viendrait fluidifier un engrenage peut-être parfois un peu rouillé. Je suis encore le réparateur d’une montre un peu fatiguée. Je me vois comme un soutien à la prise de recul, capable de poser des questions auxquelles on n’a pas forcément pensé à force de maintenir le nez dans le guidon, capable de prendre connaissance d’un métier rapidement, par l’écoute et l’analyse, capable d’accompagner l’organisation dans la transformation numérique qu’elle aspire à vivre, de lui tenir la main pour éviter qu’elle ne trébuche et de l’aider à se relever après qu’elle ait fait de mauvais choix en suivant de mauvais conseils.
Pour concevoir une application, comme pour écrire un livre, il faut un style, une structure, une âme, une intention. Le NoCode peut être la machine à écrire sur laquelle s’écrit l’histoire, le concepteur en est l’éditeur, mais c’est le métier qui en reste l’auteur.
Alors non, le NoCode ne fera pas le café, il ne pensera pas à votre place, il ne sauvera pas votre startup bancale et il ne vous évitera pas de réfléchir mais, entre de bonnes mains, il peut devenir un formidable levier d’intelligence collective, un outil de reconnexion entre les métiers et leur vrai travail qui ne devrait pas consister à passer des heures à modifier et envoyer des tableurs ou à chercher les données qu’ils doivent analyser ou piloter.
C’est peut-être là, dans cette reconnexion, que commence la vraie transformation numérique à laquelle on aspire. Il ne s’agira pas seulement de technologie, il s’agira plutôt du travail, de l’intelligence, du temps gagné. Il s’agit enfin et surtout de redonner de la valeur aux personnes qui font, et ça, aucun outil, même NoCode, ne pourra le faire à notre place.
Si vous avez lu jusqu’ici, peut-être que vous aurez envie de m’offrir un café avant de prendre rendez-vous avec moi pour parler de cet article ou de comment je peux vous simplifier la vie.
- Sans aucune formation. ↩︎
Laisser un commentaire