Une journée dans la vie d'un développeur Rust : du café du matin au cargo du soir

Matin : code, café et compilateur

Dans le monde de la programmation système, Rust occupe une place particulière. Il allie la vitesse du C++ à la sécurité mémoire garantie par le compilateur au niveau des types. Mais à quoi ressemble réellement la journée de travail d'un développeur qui code en Rust ? Oubliez les stéréotypes sur les « programmeurs système ennuyeux » — aujourd'hui, nous analysons une journée réelle dans la vie d'un ingénieur Rust. Sans fioritures, avec de vrais extraits de code et des problèmes concrets.

Imaginez : 9h00 du matin. Vous ouvrez votre ordinateur portable, lancez le terminal et voyez un message du CI : « Build failed ». Vous soupirez, ouvrez cargo check et plongez dans le monde du borrow checker. Bienvenue dans une journée de développeur Rust.

Matinée standard : revue de code et tickets

Première chose : la vérification des pull requests. Dans les équipes Rust, la revue de code est particulièrement importante car le compilateur détecte beaucoup d'erreurs, mais la logique et l'architecture sont vérifiées par les humains. Vous regardez la PR d'un collègue qui ajoute un nouveau module pour le traitement de la configuration.

// config.rs — analyse de la configuration\nuse serde::Deserialize;\nuse std::path::Path;\n\n#[derive(Debug, Deserialize)]\nstruct AppConfig {\n    host: String,\n    port: u16,\n    max_connections: u32,\n    db_url: String,\n}\n\nfn load_config(path: impl AsRef<Path>) -> Result<AppConfig, ConfigError> {\n    let content = std::fs::read_to_string(path.as_ref())?;\n    let config: AppConfig = toml::from_str(&content)?;\n    Ok(config)\n}

Vous remarquez : il n'y a pas de vérification des chaînes vides. Vous ajoutez un commentaire : « Et si host était vide ? Peut-être ajouter une validation via validator ? » 15 minutes plus tard, le collègue répond : « D'accord, j'ai ajouté #[validate] ». La journée commence de manière productive.

Partie principale : immersion dans le code

10h00 — Travail avec l'asynchrone et tokio

Vous passez à votre tâche : réécrire le serveur HTTP qui traite les webhooks. L'ancien code est écrit avec des threads bloquants et il ralentit. Votre outil — tokio et async/await. Rust est parfait pour les systèmes à forte charge, et vous le savez.

Vous écrivez un nouveau gestionnaire :

use axum::{\n    routing::post,\n    Router,\n    Json,\n};\nuse serde_json::Value;\n\nasync fn handle_webhook(Json(payload): Json<Value>) -> String {\n    // Validation, traitement, écriture en BDD\n    println!("Webhook reçu : {:?}", payload);\n    tokio::time::sleep(std::time::Duration::from_millis(100)).await;\n    "OK".to_string()\n}\n\n#[tokio::main]\nasync fn main() {\n    let app = Router::new()\n        .route("/webhook", post(handle_webhook));\n\n    axum::Server::bind(&"0.0.0.0:3000".parse().unwrap())\n        .serve(app.into_make_service())\n        .await\n        .unwrap();\n}

Vous lancez cargo run — aucune erreur. Rust prouve une fois de plus sa fiabilité. Mais ce n'est que le début.

11h30 — Bataille avec le borrow checker

Soudain, un rapport de bug arrive : « Panique lors du traitement de la liste des utilisateurs ». Vous ouvrez le code et voyez le problème : le pointeur &mut est utilisé à plusieurs endroits. Rust ne vous laissera pas vous tirer une balle dans le pied, mais parfois il se bat avec vous pour le droit de possession.

Voici le fragment problématique :

fn process_users(users: &mut Vec<User>) {\n    let admin = users.iter_mut().find(|u| u.role == Role::Admin).unwrap();\n    admin.do_task(); // emprunt mutable\n    // et ici on veut réutiliser users\n    let count = users.len(); // ERREUR ! users est déjà emprunté\n}

Vous corrigez en séparant la logique :

fn process_users(users: &mut Vec<User>) {\n    // D'abord trouver l'index, puis travailler\n    if let Some(admin_idx) = users.iter().position(|u| u.role == Role::Admin) {\n        let admin = &mut users[admin_idx];\n        admin.do_task();\n    }\n    // Maintenant on peut utiliser users en toute sécu