Ingénieur logiciel : fondamentaux, Git et premier projet pour décrocher un poste

Objectifs pratiques

À la fin de cette leçon, tu auras une fiche Poste cible : 3 offres de développeur junior analysées dans un tableau, 5 critères récurrents, et une preuve à produire pour chacun. Cette fiche sert de boussole pour tout le mois. Elle t'évite d'apprendre au hasard et te rapproche de ton objectif d'emploi.

Pourquoi c'est utile pour votre objectif

Tu disposes d'environ 14 heures réelles sur le mois (28 séances de 30 minutes). Ce n'est pas assez pour être embauché en 30 jours, mais c'est assez pour être candidatable. Cela veut dire : 1 projet livré et testé, un GitHub propre, un CV et un LinkedIn orientés développement, puis 5 à 10 candidatures ciblées. Pour y arriver, il faut savoir quel poste viser. Sinon, tu risques de te disperser entre plusieurs langages et plusieurs métiers.

Cartographier les métiers

Dans les offres, les intitulés se chevauchent. Voici les repères utiles pour un débutant.

• Développeur back-end : écrit la logique côté serveur, les bases de données et les API. Python, PHP/Laravel ou Java sont fréquents.
• Développeur front-end : construit ce que l'utilisateur voit (HTML, CSS, JavaScript, React).
• Développeur full stack : fait les deux, à un niveau souvent moins profond.
• Testeur / QA : vérifie que le logiciel marche, écrit des scénarios et des tests automatisés. C'est une porte d'entrée possible.
• Ingénieur logiciel : intitulé plus large. Il peut insister sur la conception, la qualité et le travail en équipe.

À noter : le détail des rôles QA, DevOps et mobile n'a pas été vérifié en profondeur. Fie-toi donc à ce que disent les offres réelles que tu lis.

Méthode pas à pas

1. Choisis 3 à 5 offres juniors sur LinkedIn, sur un site d'emploi local ou sur la page carrières d'une entreprise de ton pays. Cherche « développeur junior », « stagiaire développeur » et « testeur logiciel ».
2. Crée un tableau avec les colonnes : intitulé, entreprise, langage, outils (Git, SQL, API REST), niveau demandé, lieu ou télétravail.
3. Surligne les mots qui reviennent dans au moins 2 offres sur 3. Retiens-en 5 : par exemple Git, base de données, API REST, POO, un langage précis.
4. Pour chaque critère, note une preuve réalisable ce mois-ci. Exemple : Git donne un dépôt avec un commit par jour. Base de données donne un fichier de données lu par le programme. POO donne une classe dans le projet.
5. Sépare ce qui est faisable en 14 h de ce qui ne l'est pas. Mets le reste dans une colonne « plus tard ».
6. Choisis un poste cible et justifie-le en 3 lignes : ce que le poste demande, ce que tu sais déjà faire, ce que tu prouveras ce mois-ci.
7. Ouvre ton dépôt GitHub du mois et dépose la fiche dans un fichier poste-cible.md. Ce sera ton premier commit.

Exemple concret

Tu trouves trois offres juniors. L'une demande Python et Git. La deuxième demande PHP/Laravel et MySQL. La troisième demande Python, une API REST et des tests. Git apparaît 3 fois, Python 2 fois, API REST 2 fois, base de données 2 fois, tests 1 fois. Tes 5 critères deviennent : Git, Python, base de données, API REST, tests. Pour le mois, tu choisis « développeur Python junior ». Ta preuve sera un petit outil en ligne de commande qui analyse un relevé Mobile Money simulé, avec des tests et un README clair.

Erreurs à éviter

• Viser trop large : « je veux faire tout le développement ». Choisis un seul poste.
• Lire les offres sans les noter : sans tableau, tu ne vois pas les récurrences.
• Copier une liste de technologies sans te demander comment tu les prouves.
• Se fixer « être embauché ce mois-ci » : l'objectif réaliste est d'être candidatable.
• Croire les salaires des blogs : ce sont des chiffres indicatifs, jamais des promesses.

À faire maintenant

Crée ta fiche Poste cible (tableau + 5 critères + preuves + justification en 3 lignes) et commite-la dans ton dépôt GitHub. Garde-la sous les yeux : elle guidera le choix de ton projet, de ton CV et de tes candidatures.

Objectifs pratiques

À la fin de cette leçon (environ 30 minutes), vous aurez un dépôt public nommé 30-jours-code, un README qui contient votre objectif du mois et votre planning de 30 minutes par jour, et un premier commit au message clair. Vous n'installez rien : tout se fait depuis le navigateur, même sur un téléphone ou un PC partagé. Ce dépôt est la base de votre portfolio. Il prouve aussi aux recruteurs que vous codez régulièrement.

Pourquoi c'est utile pour votre objectif

Votre objectif est de décrocher un poste d'entrée. En 30 minutes par jour sur un mois, vous disposez d'environ 14 heures de pratique. Le but réaliste est donc d'être « candidatable » : un projet livré, un GitHub propre, un CV orienté développement et quelques candidatures ciblées. Un recruteur ouvre souvent votre profil GitHub avant de vous répondre. Un dépôt avec un README clair et des commits réguliers vaut mieux qu'un profil vide. Commencer dès aujourd'hui crée aussi l'habitude d'un commit par jour.

Les trois idées à retenir

Git suit le cycle suivant : un fichier est modifié, puis indexé (on choisit ce qui part dans le commit), puis validé (le commit enregistre une photo de l'état du projet). Depuis l'interface web, GitHub fait l'indexation et la validation en un seul clic sur « Commit changes ». Le cycle existe quand même, et vous le retrouverez en ligne de commande en semaine 2.

Un message de commit clair décrit ce qui change, à l'impératif et en une ligne. Exemple : « Ajoute le planning hebdomadaire au README ». À éviter : « maj », « test », « truc ».

Un dépôt public est visible par tous. Il sert de preuve de régularité : la grille de contributions se remplit jour après jour.

Méthode pas à pas

1. Créez un compte sur github.com si ce n'est pas fait. Choisissez un nom d'utilisateur sobre et professionnel, car il apparaîtra sur votre CV.
2. Cliquez sur « New repository ». Nommez-le exactement 30-jours-code.
3. Ajoutez une description courte, par exemple « Mon mois de pratique Python pour devenir candidatable ».
4. Choisissez Public.
5. Cochez « Add a README file », puis cliquez sur « Create repository ». GitHub crée déjà un premier commit automatique, mais vous allez faire le vôtre.
6. Ouvrez README.md, cliquez sur l'icône crayon (Edit) et remplacez le contenu par les sections décrites ci-dessous.
7. Cliquez sur « Commit changes ». Écrivez un message explicite, par exemple « Ajoute objectif du mois et planning hebdomadaire ». Laissez l'option de commit directement sur la branche principale.
8. Rechargez la page du dépôt. Vérifiez que le README s'affiche bien et que le commit apparaît dans l'historique (icône horloge « History »).

Contenu minimal du README

Utilisez le format Markdown. Le README contient un titre # 30 jours de code, une section `

Objectif du mois, une section

Planning (30 min/jour) et une section

Suivi`.

• Objectif du mois : une phrase mesurable, par exemple « Livrer un outil en ligne de commande Python testé, avec un README, et envoyer 5 candidatures ciblées ».
• Planning : un tableau ou une liste par jour. Exemple : lundi, variables et conditions ; mardi, boucles ; mercredi, fonctions ; jeudi, projet ; vendredi, débogage ; samedi, Git et README ; dimanche, révision et auto-évaluation.
• Suivi : une ligne par jour avec la date et ce que vous avez fait. Vous la complèterez par un commit quotidien.

Exemple concret

Une apprenante travaille le soir sur son téléphone, avec une connexion limitée. Elle crée le dépôt en 5 minutes. Elle écrit comme objectif : « Écrire un script Python qui analyse un relevé Mobile Money simulé ». Son planning prévoit 30 minutes à 20 h chaque jour. Son premier commit s'intitule « Ajoute objectif et planning de la semaine 1 ». Le lendemain, elle ajoute une ligne de suivi avec le message « Ajoute suivi du jour 2 ». En quelques jours, son historique montre une pratique régulière et lisible.

Erreurs à éviter

• Laisser le README vide ou avec le texte par défaut : c'est la première chose qu'un recruteur lit.
• Écrire des messages de commit vagues (« maj », « fichier »).
• Mettre le dépôt en privé : il ne prouve alors rien.
• Planifier trop grand (2 heures par jour). Gardez 30 minutes, c'est tenable.
• Publier des données personnelles réelles. Utilisez uniquement des données simulées.
• Attendre d'avoir « du bon code » pour commencer. Un commit minuscule vaut mieux que zéro commit.

À faire maintenant

Créez le dépôt public 30-jours-code. Rédigez le README avec votre objectif du mois et votre planning hebdomadaire de 30 minutes par jour. Faites au moins 1 commit au message explicite. Livrable : copiez l'URL du dépôt et vérifiez que vous pouvez l'ouvrir en navigation privée. Demain, vous ferez un deuxième commit pour lancer la série.

Objectifs pratiques

Dans cette leçon, tu écris ton premier vrai script Python : frais.py. Il demande un montant fictif en FCFA, calcule des frais de transfert et affiche un récapitulatif propre. Tu apprends à choisir le bon type (int, float, str), à convertir une saisie et à utiliser une f-string. Ce script sera ton premier fichier commité dans exercices/, une preuve visible de régularité pour un recruteur.

Pourquoi c'est utile pour ton objectif

Ton but est d'être « candidatable » en un mois, avec environ 14 h de pratique au total. Un recruteur qui ouvre ton GitHub veut voir du code qui tourne, lisible, avec des commits réguliers. Les variables, les types et l'affichage sont la base de tout ce qui suit : conditions, boucles, fonctions, puis ton mini-projet en ligne de commande. Toutes les données sont simulées (aucun vrai compte Mobile Money).

Les notions à retenir

• Variable : un nom qui garde une valeur. Exemple : montant = 15000.
• int : nombre entier. C'est le bon choix pour le FCFA, qui n'a pas de centimes en pratique, et il évite les erreurs d'arrondi des décimaux.
• float : nombre à virgule. Utile pour un taux comme 0.015, mais à éviter pour stocker un montant.
• str : texte, comme "Transfert fictif".
• bool : True ou False.
• input() : lit ce que l'utilisateur tape. Il renvoie toujours un str, donc il faut convertir avec int(...).
• f-string : une chaîne préfixée par f où l'on insère des variables entre accolades : f"Total : {total} FCFA".

Méthode pas à pas

1. Crée le dossier exercices/ dans ton dépôt GitHub du mois, puis le fichier frais.py (via l'interface web de GitHub ou ton éditeur).
2. Déclare les constantes en haut du fichier : TAUX_FRAIS = 0.015 (float) et devise = "FCFA" (str).
3. Lis la saisie et convertis-la tout de suite : montant = int(input("Montant à envoyer (FCFA) : ")).
4. Calcule les frais, puis arrondis en entier : frais = round(montant * TAUX_FRAIS).
5. Calcule le total : total = montant + frais.
6. Affiche avec des f-strings : print(f"Montant : {montant} {devise}"), puis les lignes des frais et du total.
7. Lance le script avec python frais.py, teste avec 10000, 25000 et 0, puis commite avec un message clair : Ajoute frais.py : calcul de frais fictifs.

Exemple concret

``python TAUX_FRAIS = 0.015 # float : taux fictif de 1,5 % devise = "FCFA" # str montant = int(input("Montant à envoyer (FCFA) : ")) # int frais = round(montant * TAUX_FRAIS) # round renvoie un int total = montant + frais envoi_valide = montant > 0 # bool print(f"Montant : {montant} {devise}") print(f"Frais : {frais} {devise}") print(f"Total : {total} {devise}") print(f"Envoi valide : {envoi_valide}") ``

Avec 20000, le script affiche des frais de 300 FCFA et un total de 20300 FCFA. Ce script utilise quatre types différents, ce qui couvre le critère des trois types minimum.

Erreurs à éviter

• Oublier int() : "20000" * 0.015 provoque un TypeError. Lis la traceback de bas en haut : la dernière ligne te dit quoi, la ligne au-dessus te dit où.
• Oublier le f devant la chaîne : tu verras {montant} affiché tel quel.
• Stocker un montant en float : on risque des résultats comme 300.00000000000006. Garde des int.
• Copier-coller sans comprendre : change le taux, relance, et prédis le résultat avant de lancer.
• Taper du texte à la place d'un nombre : int("abc") plante avec un ValueError. Ne masque pas l'erreur avec un try/except à ce stade. Nous gérerons ce cas proprement dans une prochaine leçon.

À faire maintenant

Crée exercices/frais.py selon la méthode, teste-le avec 3 montants et commite-le. Livrable : le lien vers ton fichier sur GitHub, plus une mini-checklist de 3 lignes (« s'exécute sans erreur », « 3 types différents », « saisie convertie en int »). Va plus loin : fais varier le taux, ajoute une variable nom_destinataire (str) et affiche-la dans le récapitulatif.

Objectifs pratiques

Dans cette leçon, tu vas écrire un barème de frais par tranches avec if/elif/else, mais surtout définir 4 cas de test AVANT de coder. C'est un réflexe très attendu en entretien technique et il te rapproche directement de ton objectif : être « candidatable » ce mois-ci avec un dépôt GitHub qui montre une démarche professionnelle. Durée prévue : 30 minutes.

Pourquoi c'est utile pour votre objectif

Un recruteur ne regarde pas seulement si ton code marche. Il regarde si tu sais raisonner : quelles entrées, quelles sorties, quels cas limites. Écrire les tests d'abord, c'est prouver que tu as compris le problème avant d'écrire la solution. Ce sera aussi la base du mini-projet CLI du mois et de ton README de portfolio (un tableau de cas est très lisible).

Le ccadre : un barème fictif

On utilise un barème de frais de transfert Mobile Money entièrement fictif (aucune donnée réelle) :

• Montant de 1 à 5 000 : frais de 100
• Montant de 5 001 à 20 000 : frais de 250
• Montant au-dessus de 20 000 : frais de 500
• Montant de 0 ou négatif : invalide (on renvoie un message d'erreur)

Méthode pas à pas

1. Écris le barème en français dans ton README, tranche par tranche, en précisant si les bornes sont incluses (« 5 000 inclus dans la première tranche »). Une borne floue est la première source de bug.
2. Liste 4 cas de test (entrée → sortie attendue) avant tout code. Choisis-les pour couvrir chaque comportement, dont au moins une valeur limite :

• 3 000 → 100 (milieu de tranche 1)
• 5 000 → 100 (valeur limite : borne haute de la tranche 1)
• 5 001 → 250 (juste après la borne)
• 0 → « invalide » (cas d'erreur)

1. Crée bareme.py et écris une fonction calculer_frais(montant). Ordre des conditions : d'abord le cas invalide, puis les tranches de la plus petite à la plus grande.
2. Utilise if / elif / else : une seule branche s'exécute, donc elif montant <= 20000 est déjà sûr que montant > 5000.
3. Vérifie chaque cas avec des assert (ou des print) en bas du fichier.
4. Si un cas échoue, ne modifie qu'une seule chose à la fois, relance, observe. Ne change jamais le résultat attendu pour « faire passer » le test sans te demander si le barème était mal compris.
5. Commit avec un message clair, par exemple « Ajoute bareme.py avec 4 cas de test ».

Exemple concret

```python def calculer_frais(montant): if montant <= 0: return "invalide" elif montant <= 5000: return 100 elif montant <= 20000: return 250 else: return 500

assert calculer_frais(3000) == 100 assert calculer_frais(5000) == 100 assert calculer_frais(5001) == 250 assert calculer_frais(0) == "invalide" print("Tous les cas passent") ```

Si tu avais écrit < 5000 au lieu de <= 5000, le test sur 5 000 aurait échoué immédiatement : c'est exactement le rôle de la valeur limite.

Erreurs à éviter

• Écrire le code puis inventer des tests qui lui donnent raison : tu ne détectes plus rien.
• Oublier les bornes : < et <= ne sont pas interchangeables.
• Mauvais ordre des elif : si tu testes montant > 0 en premier, le cas invalide disparaît ou les tranches se mélangent.
• Remplacer elif par plusieurs if sans comprendre : plusieurs branches peuvent s'exécuter.
• Copier-coller une solution IA sans la tester : lance tes 4 cas pour la vérifier.

À faire maintenant

Livrable : un fichier bareme.py et un tableau de cas dans le README de ton dépôt du mois.

1. Invente ton propre barème fictif (3 tranches + cas invalide).
2. Écris dans le README un tableau à 4 lignes : entrée / sortie attendue / résultat obtenu.
3. Code bareme.py, lance-le, coche chaque ligne.
4. Fais un commit.

Pourquoi cet exercice t'aide à décrocher un poste

Parcourir une liste pour calculer un total, un maximum et un compte est le geste de base de presque tous les exercices techniques d'entretien. C'est aussi le cœur des vrais outils : relevés, stocks, tontines. Avec 30 minutes par jour, ce script est ton 3e commit du dépôt du mois. Il prouve que tu sais écrire, tester et versionner un programme simple. Un recruteur peut le vérifier sur ton GitHub.

Durée estimée : 30 à 40 minutes. Le script fait moins de 40 lignes.

Contexte

Tu disposes d'un relevé Mobile Money simulé. Aucune donnée réelle n'est utilisée. Voici les 10 montants en FCFA :

[12500, 75000, 3000, 52000, 150000, 800, 49999, 60000, 25000, 98000]

Tu dois produire releve.py, qui analyse cette liste.

Étapes pas à pas

Étape 1 : préparer les données et le seuil

En haut du fichier, crée la liste montants. Crée aussi une variable SEUIL = 50000. Le seuil doit être modifiable en changeant une seule ligne.

Étape 2 : boucle for avec accumulateurs

Initialise total = 0, maximum = montants[0] et nb_au_dessus = 0. Parcours la liste avec for montant in montants:. À chaque tour, ajoute le montant au total. Si le montant dépasse maximum, mets à jour maximum. S'il est strictement supérieur à SEUIL, incrémente nb_au_dessus.

Étape 3 : afficher les résultats

Affiche avec print : le total, le maximum, le nombre d'opérations au-dessus du seuil, et le nombre total d'opérations.

Étape 4 : version while (bonus)

Réécris le parcours avec une boucle while et un index i. La condition d'arrêt est i < len(montants). Vérifie que tu obtiens les mêmes résultats. Pense à incrémenter i, sinon la boucle ne s'arrête jamais.

Étape 5 : vérifier à la main

Calcule le total sur papier ou à la calculatrice, puis compare avec ton script. Résultat attendu : total = 526 299, maximum = 150 000, 5 montants strictement au-dessus de 50 000. Si ton résultat diffère, ajoute un print(montant) dans la boucle. Lis la traceback de bas en haut et change une seule chose à la fois.

Étape 6 : commiter

Ajoute releve.py au dépôt, via l'interface web de GitHub ou en local. Utilise un message clair, par exemple : Ajoute releve.py : total, maximum et seuil sur relevé simulé.

Erreurs à éviter

• Initialiser maximum = 0 : cela casse si tous les montants sont négatifs. Préfère le premier élément.
• Écrire >= au lieu de > : 50 000 exact ne doit pas être compté.
• Coder le seuil en dur à plusieurs endroits.
• Copier-coller une solution sans pouvoir expliquer chaque ligne.
• Un message de commit vague comme « update ».

Livrables attendus

1. Le fichier releve.py fonctionnel.
2. Une capture ou un copier-coller de la sortie du script.
3. Le lien vers ton commit sur GitHub.

Critères de réussite

• Total et maximum corrects sur la liste fournie.
• Seuil modifiable en une seule ligne.
• Script commité avec un message clair.
• Tu sais expliquer à voix haute le rôle de chaque accumulateur.

Auto-évaluation

Change SEUIL à 20 000 puis relance. Prédis le résultat avant de lancer : 7 montants doivent dépasser ce seuil. Si ta prédiction est juste, tu as compris la boucle.

Pourquoi cet exercice

Tu viens de terminer la semaine 1. Avec 30 minutes par jour sur un mois, tu disposes d'environ 14 h au total. Chaque séance compte, et sans mesure tu ne sais pas si tu avances ou si tu tournes en rond. Le tutoriel sans pratique est l'erreur classique du débutant. Un tableau de bord de progression te montre des faits : jours codés, commits, scripts réussis. Il te permet aussi de corriger ton plan avant que le retard ne s'installe. Cela te rapproche de ton objectif : être « candidatable » à la fin du mois, avec un GitHub régulier, un projet livré et des candidatures ciblées.

Objectif pratique

Créer un fichier SUIVI.md à la racine de ton dépôt GitHub du mois. Il contient le bilan chiffré de la semaine 1 et un plan d'ajustement pour la semaine 2. Tu le commites avec un message clair.

Durée estimée

30 minutes, en une seule séance.

Méthode pas à pas

Étape 1 : relever tes chiffres (10 min)

Ouvre l'onglet « Commits » de ton dépôt et compte les faits, sans les arrondir à ton avantage :

• Nombre de jours codés sur 7 (objectif : au moins 5).
• Nombre de jours avec au moins un commit.
• Nombre de commits au total.
• Nombre de scripts Python qui fonctionnent. Ce sont ceux sur les cas Mobile Money simulés (variables, conditions, boucles) que tu peux relancer sans erreur.
• Minutes de code cumulées, estimées.

Étape 2 : identifier un blocage (5 min)

Choisis le blocage le plus coûteux de la semaine, par exemple une traceback incomprise, une boucle infinie ou une erreur Git. Décris-le en trois lignes : ce que tu voulais faire, ce qui s'est passé, ce que tu as déjà essayé. Écris ensuite une action corrective concrète et mesurable. Exemple : « lire la traceback de bas en haut et tester avec la plus petite entrée possible ». Autre exemple : « relire la section de la doc Python sur les boucles for ».

Étape 3 : écrire un ajustement (5 min)

Choisis un seul changement pour la semaine 2, avec un chiffre. Exemple : « coder à heure fixe, 20h00, 6 jours sur 7 » ou « faire un commit par script terminé ».

Étape 4 : rédiger et commiter (10 min)

Crée SUIVI.md sur GitHub (bouton « Add file ») ou en local. Utilise la structure ci-dessous, puis commite avec un message du type « Ajout du bilan de la semaine 1 ».

Modèle de fichier

Semaine 1, date du jour. Tableau avec les colonnes Indicateur, Valeur et Cible. Ajoute ensuite les rubriques « Blocage » et « Action corrective », puis « Ajustement semaine 2 », et enfin une auto-évaluation de 1 à 5 sur la confiance en Python.

Erreurs à éviter

• Écrire des généralités (« je dois travailler plus ») sans chiffre.
• Cacher un mauvais résultat : 2 jours codés sur 7 est une information utile, pas un échec.
• Choisir plus de trois ajustements : tu n'en tiendras aucun.
• Oublier de commiter : sans commit, le livrable n'existe pas.

Livrables attendus

• Un fichier SUIVI.md daté, présent dans ton dépôt.
• Un commit visible dans l'historique.

Critères de réussite

• Au moins 4 indicateurs chiffrés renseignés.
• 1 blocage identifié avec une action corrective précise.
• Fichier commité et visible sur GitHub.