No-code et automatisation

Ce que couvre cette catégorie

Créer et automatiser le travail sans écrire de code : créateurs visuels d’applications, automatisation de flux entre produits, créateurs d’outils internes et les bibliothèques de connecteurs qui rendent tout cela possible.

Deux promesses distinctes se vendent ici. L’une est de remplacer un tableur par quelque chose qui a des permissions et un vrai formulaire. L’autre est de supprimer l’étape manuelle où quelqu’un copie chaque matin des données d’un système à l’autre.

L’intégration et le test orientés développeurs se trouvent dans API et intégrations. Les assistants pilotés par des modèles relèvent des outils d’IA.

L’automatisation, et comment fonctionne le comptage

L’automatisation par connecteurs est l’achat le plus courant et le plus facile à mal chiffrer.

Les produits comptent l’usage en tâches, exécutions, étapes ou opérations, et les différences ne sont pas cosmétiques. Un scénario de huit étapes qui se déclenche toutes les quinze minutes donne un tout autre nombre en comptage par étape qu’en comptage par exécution, et le compteur qui paraît généreux sur la page de tarifs peut être le plus cher.

Avant de comparer les formules, notez combien de scénarios vous prévoyez, à quelle fréquence chacun se déclenche, combien d’étapes il contient et à quoi ressemble un mois chargé. Vérifiez ensuite si les tentatives échouées, les exécutions filtrées, les vérifications d’interrogation et les exécutions de test sont facturées. Dans plusieurs produits, elles le sont.

Les intervalles d’interrogation comptent autant que le prix. Un produit qui cherche de nouveaux enregistrements toutes les quinze minutes ne peut pas soutenir ce qui doit sembler immédiat, et les déclencheurs instantanés sont souvent réservés aux niveaux supérieurs.

La fiabilité est la partie qu’on saute

Un scénario qui tourne en silence pendant six mois est invisible jusqu’au matin où il s’arrête.

• Nouvelles tentatives, avec un délai croissant raisonnable plutôt qu’un second échec immédiat.
• Visibilité des erreurs, qui atteint une personne plutôt qu’un journal que personne n’ouvre.
• Rejeu, pour répéter une exécution une fois la cause corrigée.
• Idempotence, pour qu’une exécution répétée ne crée pas deux enregistrements.
• Historique, assez long pour investiguer ce que l’on remarque une semaine plus tard.

Demandez à quoi ressemble concrètement une exécution échouée. Les produits diffèrent fortement ici, et la différence ne se voit que sous pression.

Créer des applications sans code

Les créateurs d’outils internes remplacent tableurs, documents partagés, formulaires papier et la demande qui arrive par message.

Jugez-les d’abord sur les données. Où elles vivent, si elles peuvent se connecter à une base que vous exploitez déjà, et ce qui se passe quand une table atteint cent mille lignes. Beaucoup de produits sont excellents à mille et inutilisables à cent mille.

Regardez ensuite les permissions, car c’est généralement la raison pour laquelle le tableur devait disparaître. Accès par ligne, rôles, étapes de validation et piste d’audit décident si le résultat est une amélioration ou une version plus jolie du même problème.

Gouvernance, ou le foisonnement qui suit le succès

Ces plateformes réussissent en laissant n’importe qui construire, et c’est aussi ainsi qu’elles échouent.

En un an, une organisation peut compter deux cents scénarios, dont quarante comptent, douze sont cassés, et plusieurs ont été construits par des gens qui sont partis depuis. Personne ne sait lesquels sont lesquels.

Fixez des conventions tôt : un modèle de nommage, un responsable consigné pour chaque scénario, et une revue périodique qui supprime ce que rien n’utilise. Demandez si le produit prend en charge des environnements, des versions, et le passage d’une réalisation d’un compte personnel à un compte partagé. Cette dernière transition est l’origine de la plupart des mystères hérités.

La sécurité mérite la même attention. Une plateforme d’automatisation détient les identifiants de chaque système qu’elle touche, ce qui la rend plus précieuse pour un attaquant que la plupart des outils qu’elle connecte. Cherchez des connexions à portée limitée, un stockage partagé des identifiants et un journal d’audit qui montre qui a changé quoi, avec les habitudes tarifaires décrites dans ce que cachent les pages de tarifs.

Décider ce qu’il ne faut pas automatiser

La valeur de cette catégorie est évidente, et la discipline qu’elle exige est de décider où s’arrêter.

Automatisez le travail répétitif, bien compris et stable. Un processus qui change toutes les quelques semaines passera plus de temps à être reconstruit qu’il n’en aura jamais fait gagner.

Laissez de côté tout ce où une erreur est coûteuse et silencieuse. Les mouvements d’argent, les communications clients à grande échelle et les modifications d’enregistrements dont d’autres systèmes dépendent méritent une étape humaine ou une validation stricte, car une erreur d’automatisation se répète à la vitesse d’une machine.

Soyez prudent avec les processus que personne n’a écrits. Les automatiser fige la version actuelle, quelle qu’elle soit, y compris les parties qui existent à cause d’un contournement d’il y a deux ans.

Là où la logique est vraiment complexe, un court script entretenu par quelqu’un qui sait le lire vaut souvent mieux qu’un scénario visuel de quarante étapes que seul son auteur comprend.