Livrer quelque chose de petit cette semaine

La plupart des gens coincés dans des boucles de tutoriels n'ont pas un problème de compétences. Ils ont un problème de livraison. Tu peux regarder quarante heures de contenu Python et rester bloqué dès que tu t'assieds pour construire quelque chose par toi-même, parce que les tutoriels suppriment chaque décision pour toi. Ce guide est un forçage : choisis quelque chose de petit, termine-le, mets-le devant quelqu'un, cette semaine.

Choisis un projet que tu peux terminer en un weekend

Le mode de défaillance ici est la portée. Les gens décident que leur premier projet devrait être une app SaaS avec auth, facturation et tableau de bord. C'est un projet de six mois déguisé en weekend.

À la place choisis quelque chose avec une fonction unique et claire :

• Un outil CLI qui renomme les fichiers dans un dossier en fonction de la date EXIF
• Un script qui fait du scraping d'une API publique et t'envoie un résumé quotidien par email
• Une app Flask avec un formulaire et une page de résultat
• Une extension de navigateur qui met en surbrillance un mot-clé sur toute page que tu visites

Écris la portée en une phrase avant d'écrire du code. Si la phrase a besoin de « et » plus d'une fois, coupe-la. « Un outil qui suit mes dépenses et les catégorise aussi et les représente en graphiques » c'est trois projets. Livre d'abord le suivi.

Fixe une vraie deadline et un vrai public

Une deadline sans conséquence n'est pas une deadline. Dis-le à un ami, publie sur un serveur Discord, ou engage-toi à la montrer à un collègue vendredi. Le public importe plus que la deadline — savoir que quelqu'un regardera vraiment la chose change comment tu la construis. Tu arrêtes de surpolir l'architecture et tu commences à t'assurer que le chemin heureux fonctionne vraiment.

Donne-toi un nombre, pas une ambiance. « Je vais y travailler quand j'aurai le temps » ne produit rien. « Deux heures ce soir, deux heures demain, livraison samedi matin » produit un projet.

Construis la version moche d'abord

Saute les débats sur la structure des dossiers, saute le choix d'un framework CSS, saute de décider entre Postgres et SQLite pour un outil qui stockera quarante lignes. Écris un fichier. Utilise des déclarations print() à la place d'un logger. Utilise une liste Python à la place d'une base de données si c'est tout ce qu'il te faut.

# expenses.py - version moche, et c'est bien
import csv
from datetime import date

def add_expense(amount, category):
    with open('expenses.csv', 'a', newline='') as f:
        writer = csv.writer(f)
        writer.writerow([date.today().isoformat(), amount, category])

add_expense(12.50, 'coffee')

C'est un suivi de dépenses qui fonctionne. Ce n'est pas scalable, ça n'a pas de tests, et ça t'amènera à 90% de quelque chose que tu peux vraiment utiliser demain. Tu peux refactoriser une chose moche qui fonctionne. Tu ne peux pas refactoriser une belle chose qui n'existe pas.

Déploie-le quelque part, même mal

Un projet sur ton ordinateur portable ne compte pas comme livré. Mets-le devant Internet ou devant une personne qui l'exécute elle-même.

• Outil CLI : pousse-le vers un repo GitHub public avec un README de deux paragraphes montrant les commandes d'installation et d'exécution exactes
• App web : déploie sur Render, Fly.io, ou un droplet DigitalOcean à 5 dollars — ne passe pas trois jours à comparer les options Kubernetes pour un projet avec un utilisateur
• Script : configure un cron job ou GitHub Action pour qu'il s'exécute sans que tu le touches

La friction de déploiement tue plus de side projects que n'importe quel défi technique. Si faire un git push vers une plateforme comme Render c'est trop pour maintenant, enregistre juste une vidéo Loom de 90 secondes de son exécution locale et envoie ça. L'idée c'est une preuve externe que ça fonctionne, pas la maturité de l'infrastructure.

Note ce qui a cassé

Après la livraison, passe quinze minutes à écrire trois choses qui ont mal tourné et comment tu les as corrigées. Pas pour quelqu'un d'autre — pour toi. C'est l'apprentissage réel. Le tutoriel t'a enseigné la syntaxe. Le pip install cassé, l'erreur CORS, le bug de décalage d'une unité sur la date à minuit — ceux-là t'enseignent comment les logiciels se comportent vraiment.

Garde ces notes dans un seul fichier continu. Après cinq ou six petits projets, tu remarqueras que les mêmes catégories de bugs réapparaissent, et c'est ton vrai curriculum : les lacunes que les tutoriels ne couvrent jamais.

Puis choisis la chose suivante, légèrement plus grande

Ne saute pas d'un script CLI à un système distribué. Ajoute une dimension de complexité à la fois : le projet suivant obtient une base de données au lieu d'un CSV, ou une suite de tests basique, ou un deuxième utilisateur. Les petites étapes composées battent une réécriture ambitieuse qui stagne à la semaine trois.

Si tu veux des étapes structurées après ceci, les segments Python et DevOps de Korra Studio couvrent exactement les lacunes de déploiement et d'outillage qui tendent à piéger les gens juste après leur premier projet livré.