Blocs sans code ou Python : par lequel commencer vraiment ?

La réponse honnête : commencez par les blocs, et sachez à l'avance quelles trois choses vous pousseront vers Python. Comme ça, le passage se fait quand vous en avez besoin, pas quand vous êtes coincé.

Ce qu'un éditeur de blocs couvre réellement

Un éditeur de blocs moderne n'est pas un jouet. Enchaîner des actions avec boucles, conditions et variables couvre plus de choses qu'on ne le croit :

• Ouvrir une app, attendre un écran, cliquer, lire un résultat
• Répéter N fois, ou jusqu'à ce qu'une condition soit vraie
• Bifurquer selon la présence d'une image ou d'un texte
• Stocker une valeur et la réutiliser plus loin dans l'exécution
• Lancer la même séquence sur plusieurs appareils en même temps

Ça, c'est une boucle de récompense quotidienne complète, une routine de connexion, un contrôle-et-relevé ou une passe de QA simple. Si votre automatisation ressemble à ça, les blocs ne sont pas un compromis : c'est le bon choix, le plus rapide, et il reste lisible six mois plus tard quand vous aurez oublié comment ça marchait.

Le vrai avantage, c'est le débogage. Quand une étape échoue, le bloc fautif est mis en évidence dans l'espace de travail et l'erreur s'affiche dans la sortie : vous voyez exactement quelle carte a coincé, sans traduction mentale entre le code et le comportement.

Les trois murs

Mur numéro un : les données. Dès qu'il faut lire une valeur, faire un calcul dessus, tenir un total, comparer le chiffre d'aujourd'hui à celui d'hier, ou écrire des résultats dans un CSV, les blocs deviennent vite verbeux. Cinq cartes pour ce qu'une ligne de Python dit clairement.

Mur numéro deux : la structure. Quand les mêmes six étapes apparaissent à quatre endroits, vous voulez une fonction. Les éditeurs de blocs ont des sous-séquences, mais la réutilisation entre projets, les paramètres par défaut et tout ce qui ressemble à un module restent malcommodes.

Mur numéro trois : le monde extérieur. Appeler une API HTTP, lire du JSON, ouvrir un tableur, poster sur Discord avec une charge utile formatée, parler à une base de données. Il y a toujours un bloc pour le cas courant, et jamais un pour le vôtre.

Si aucun de ces trois murs ne décrit votre automatisation, vous n'avez pas besoin de Python. Beaucoup de gens font tourner toute leur exploitation en blocs, et ils ont raison.

Ce que Python apporte, concrètement

import csv, datetime

# Lancé sur chaque téléphone choisi dans « Lancer sur »
open_app("com.example.rewards")
wait_text("Solde", timeout=20)
balance = read_text_at(300, 370)          # texte affiché sous ce point
serial = adb("getprop ro.serialno").strip()

if balance:
    with open(f"{SCRIPT_DIR}/balances.csv", "a", newline="") as handle:
        csv.writer(handle).writerow([
            serial,
            int(balance.replace(",", "")),
            datetime.datetime.now().isoformat(),
        ])
    log(f"Solde enregistré : {balance}")
else:
    log("Solde introuvable", level="WARNING")

Une quinzaine de lignes, et ce seraient trente blocs que personne n'a envie de lire. Lire une valeur, convertir un type, l'horodater, l'ajouter à un fichier : c'est exactement la forme de chose où les blocs sont mauvais et où Python est banal.

Franchir le mur sans réécrire

La transition n'est douloureuse que si les deux modes sont deux produits différents. Quand l'éditeur de blocs et l'éditeur Python écrivent le même fichier de script, « passer à Python » veut simplement dire ouvrir l'autre vue de la même automatisation (voir l'éditeur de blocs et les scripts Python).

Ça change tout en pratique : votre premier script Python n'est pas une page blanche, c'est votre script en blocs qui fonctionne déjà, exprimé en code, avec les bons noms de fonctions et le bon ordre d'arguments. Changer une étape pour y faire un calcul est une modification d'une ligne, pas un portage.

C'est aussi la façon la plus rapide d'apprendre l'API. Vous l'avez construite en blocs, vous savez ce qu'elle fait, et vous lisez maintenant la même logique en Python. C'est un bien meilleur tutoriel que n'importe quelle page de documentation.

Où se place un assistant IA

Claude, Grok ou ChatGPT, avec le pack AppsMobs, connaissent toutes les fonctions. Un assistant qui génère un script à partir d'une phrase est utile à un moment précis : vous savez ce que vous voulez, vous savez à peu près quelles fonctions existent, et vous n'avez pas envie de taper la boucle et la gestion d'erreurs. Il produit un premier jet que vous corrigez.

Il n'est pas utile comme substitut à la compréhension. Un script généré que vous ne savez pas lire est un script que vous ne saurez pas déboguer à quatre heures du matin — c'est-à-dire au moment où les automatisations tombent. Traitez-le comme un clavier plus rapide, pas comme un ingénieur.

Un chemin concret

1. Semaine un : les blocs. Construisez l'automatisation réelle. Faites-la tourner sur un appareil. Résistez à l'envie de la généraliser.
2. Semaine deux : faites-la survivre. Ajoutez les attentes, les réessais et la sortie propre. C'est là qu'est l'essentiel du vrai travail, et c'est le même travail dans les deux modes.
3. Quand vous butez sur un mur : ouvrez la vue Python de ce que vous avez déjà, changez la seule étape qui le demandait, continuez.
4. Alors seulement : généralisez. Lancez-la sur tous vos téléphones à la fois, puis planifiez-la dans l'Automatisation.

La plupart des gens ne dépassent jamais l'étape trois, et c'est un très bon résultat. L'intérêt d'un outil, c'est ce que vous automatisez, pas l'automatisation de l'automatisation.