Python avec Google Colab : bien démarrer un projet d’équipe à distance

Google Colab est un service de notebooks Jupyter en ligne qui permet dʼécrire et dʼexécuter du code en Python depuis son navigateur web. Gratuit, accessible avec un compte Google, Colab est tout indiqué pour lʼanalyse de données et la data science avec Python, avec ses cellules de code et ses blocs de texte en syntaxe Markdown, pour structurer et commenter le code.

Un notebook créé sur Colab est enregistré sur Google Drive. En pratique, il s’agit d’un fichier .ipynb qui, une fois téléchargé sur ordinateur, peut être ouvert et utilisé en local avec Jupyter notebook. À l’inverse, un fichier .ipynb créé en local avec Jupyter notebook peut être uploadé sur Google Drive pour être édité et exécuté dans Colab pour accéder à des ressources informatiques, y compris des GPU^[1] et des TPU^[2]. Pour travailler en équipe à distance, il est possible de partager un notebook Colab comme on le ferait avec un document Google Docs. Enfin, ce notebook peut accéder aux fichiers stockés dans Google Drive, par exemple si vous travaillez avec des jeux de données au format .csv.

Mais comment procéder pour partager à la fois les notebooks qui contiennent votre code et les fichiers qui contiennent les données ? C’est là où les choses se corsent (un peu). Et il y a plusieurs manières de procéder !

Durant leur formation chez Liora (ex DataScientest), nos étudiants réalisent un projet fil rouge destiné à mettre en pratique les compétences acquises à travers un cas mis en œuvre de A à Z. Ce projet est réalisé par équipe de 2, 3 ou 4, avec des membres qui sont généralement dispersés géographiquement. Pour mettre en place rapidement et efficacement ce travail collaboratif à distance, notre équipe pédagogique propose une masterclass qui pose les bases et aborde les différentes solutions possibles. Puis chaque équipe bénéficie d’un suivi personnalisé à travers des rendez-vous réguliers avec son mentor.

Dans cet article, nous revenons sur les clés pour bien démarrer avec Google Colab en équipe. Quels sont les trucs et astuces des mentors de DataScientest ? Y a-t-il des points de vigilance à avoir ? En moins de 7 minutes, vous allez avoir une vision claire des 3 scénarios recommandés pour tout paramétrer.

Google Colab: c’est quoi et quand l’utiliser ?

Google Colab est un service de notebooks Jupyter en ligne qui permet d’écrire et d’exécuter du code en Python depuis son navigateur web. Gratuit et accessible avec un compte Google, il combine cellules de code et blocs de texte en syntaxe Markdown pour structurer et commenter le travail, ce qui le rend très pratique pour des projets d’équipe à distance où l’on a besoin de documenter, relire et itérer rapidement sans installer d’environnement local. Voir la formation Data Scientist.

Un notebook créé sur Colab est enregistré sur Google Drive au format .ipynb. Il peut être ouvert en local avec Jupyter notebook, ou importé dans Colab pour profiter de ressources de calcul, y compris des GPU et des TPU. Pour travailler en équipe à distance, on partage le notebook comme un document Google Docs, et l’on peut accéder aux fichiers stockés dans Drive, par exemple des jeux de données au format .csv.

Colab ou environnement local ou VM cloud, quand choisir quoi ? Colab convient lorsque vous devez démarrer vite sans configuration, partager immédiatement un notebook et bénéficier à la demande d’accélérateurs matériels. Les runtimes sont préconfigurés, l’assistance par IA peut générer ou expliquer du code, et les offres Pro/Pro+ donnent un accès prioritaire à des accélérateurs plus rapides, davantage de mémoire et des exécutions en arrière‑plan plus longues. En contrepartie, les sessions sont temporaires, les ressources soumises à des quotas et un même notebook ne peut être exécuté activement que par une personne à la fois. Préférez un environnement local si vous travaillez hors ligne, avec des dépendances système spécifiques ou un IDE complet et persistant. Optez pour une VM cloud ou des notebooks managés sur Google Cloud si vous avez besoin de ressources dédiées et garanties, d’exécutions longues ou planifiées, ou de contrôles stricts de sécurité et de gouvernance.

• Idéal quand: vous lancez un projet d’équipe à distance et devez explorer rapidement un jeu de données public pour aligner vos premières analyses.
• Idéal quand: vous prototypez un modèle de machine learning ou une visualisation avec GPU ou TPU, sans configuration locale, un cas d’usage classique du parcours Data Scientist.
• Idéal quand: vous organisez un cours, un atelier ou un onboarding technique, car l’accès est immédiat et l’interface réduit la courbe d’apprentissage.
• Idéal quand: vous faites une revue de code asynchrone, commentez directement dans le notebook et exploitez l’historique des versions dans Drive.
• À éviter ou à compléter quand: vous avez des entraînements très longs ou des jobs planifiés, préférez Colab Pro ou Pro+ pour une exécution en arrière-plan plus longue, ou des notebooks gérés sur Google Cloud.
• À éviter ou à compléter quand: vous manipulez des données sensibles, appliquez des partages Drive stricts et, si besoin, des contrôles IAM côté Google Cloud. En cas de collaboration très synchrone, dupliquez le notebook par membre puis fusionnez les changements.
• À éviter ou à compléter quand: vous devez travailler hors ligne, avez besoin d’un IDE complet et d’environnements persistants, privilégiez un setup local bien maîtrisé.
• À éviter ou à compléter quand: vous avez besoin de GPU/TPU réservés, de volumes de stockage élevés ou d’intégrations réseau avancées, une VM cloud ou Vertex AI sera plus adaptée.

Interface et navigation: par où commencer ?

Avant d’écrire la moindre ligne de code, prenez 2 minutes pour repérer les points d’entrée et les repères de l’interface. Colab repose sur des notebooks Jupyter enregistrés sur Google Drive au format .ipynb, avec des cellules de code et des blocs Markdown. Les menus “Fichier” et “Exécution” concentrent les commandes clefs, et la colonne latérale gauche accueille vos fichiers et la table des matières générée à partir de vos titres Markdown.

Comment ouvrir un notebook (Drive, GitHub, modèle) ?

1. Depuis Google Drive: dans Drive, cliquez sur “+ Nouveau” > Plus > Google Colaboratory, ou double‑cliquez sur un fichier .ipynb puis “Ouvrir avec > Colaboratory”. Par défaut, les nouveaux notebooks créés depuis Colab sont rangés dans le dossier “Colab Notebooks”.
2. Depuis l’interface Colab: ouvrez Colab, puis Fichier > Ouvrir un notebook (Ctrl+O). Choisissez l’onglet Google Drive, GitHub, Upload ou URL et sélectionnez votre fichier.
3. Depuis GitHub: Fichier > Ouvrir un notebook > onglet GitHub, collez l’URL d’un dépôt ou tapez utilisateur/depot, puis choisissez le notebook. Au besoin, utilisez ensuite Fichier > Enregistrer une copie dans Drive pour travailler sur une copie personnelle.
4. À partir d’un modèle ou d’un exemple: depuis la page d’accueil Colab, ouvrez un exemple proposé, puis Fichier > Enregistrer une copie dans Drive pour conserver votre version.

Conséquences sur la sauvegarde et le versioning: un notebook ouvert depuis Drive est sauvegardé automatiquement et bénéficie de l’historique des versions de Drive et du partage Drive. Un notebook ouvert depuis GitHub est lu depuis le dépôt, mais vos modifications ne sont pas poussées automatiquement, en pratique on travaille sur une copie dans Drive, puis l’on versionne via Git côté dépôt. Les modèles et exemples Colab s’ouvrent toujours en copie, ce qui évite d’écraser l’original.

Que propose l’interface (barre d’outils, Runtime, table des matières) ?

L’UI de Colab est pensée pour exécuter, inspecter et organiser rapidement vos notebooks. Voici l’essentiel pour accélérer la prise en main en équipe.

• Barre supérieure: menus Fichier, Édition, Affichage, Insertion, Runtime/Exécution, Outils, Aide. Vous y trouverez l’ouverture, l’enregistrement dans Drive, l’exécution de toutes les cellules et les paramètres clés.
• Boutons de la barre d’outils: “+ Code”, “+ Texte”, lecture de cellule, arrêt, reconnecter l’exécution, gestion du type de cellule. Ajoutez vos cellules sans quitter le flux.
• Menu Runtime/Exécution: exécuter tout, interrompre, redémarrer, “Modifier le type d’exécution” pour choisir CPU, GPU ou TPU. Pratique pour l’entraînement et l’inférence.
• Colonne de gauche: panneau Fichiers pour téléverser, télécharger, créer des dossiers et monter Google Drive. Accès rapide aux jeux de données partagés.
• Table des matières: disponible dans la colonne de gauche. Elle se construit automatiquement à partir de vos titres Markdown et permet de naviguer instantanément dans les sections du notebook.
• Terminal léger: depuis une cellule, préfixez une commande par ! pour interagir avec le système, par exemple !ls ou !pip install.
• Raccourcis et préférences: Outils > Raccourcis clavier pour tout lister, et Outils > Paramètres de l’éditeur pour activer numéros de ligne, thème, indentation et aides à la saisie.

Besoin	Où cliquer	Astuce / rappel
Lancer toutes les cellules	Runtime/Exécution > Exécuter tout	Vérifiez l’ordre d’exécution avant un run global
Interrompre / redémarrer	Runtime/Exécution > Interrompre, puis Redémarrer	Utile si une cellule boucle indéfiniment
Choisir l’accélérateur	Runtime/Exécution > Modifier le type d’exécution	GPU et TPU accélèrent fortement l’entraînement
Ouvrir / enregistrer	Fichier > Ouvrir un notebook, Enregistrer une copie dans Drive	Les notebooks sont des fichiers .ipynb stockés sur Drive
Gérer les fichiers	Panneau “Fichiers” à gauche	Glisser‑déposer possible depuis votre poste

Quels raccourcis clavier utiliser ?

Quelques raccourcis universels pour gagner du temps dès la première session. Retrouvez la liste complète via Outils > Raccourcis clavier.

Action	Raccourci	Quand l’utiliser
Exécuter la cellule et passer à la suivante	Shift+Entrée	Flux de travail classique cellule par cellule
Exécuter sans changer de cellule	Ctrl+Entrée	Répéter une exécution après un petit ajustement
Exécuter puis insérer une cellule dessous	Alt+Entrée	Explorer rapidement et enchaîner les essais
Ouvrir un notebook	Ctrl+O	Accéder aux onglets Drive, GitHub, Upload
Rechercher dans le notebook	Ctrl+F	Retrouver une variable, un titre ou un message d’erreur
Commenter / décommenter la sélection	Ctrl+/	Nettoyer un bloc de code à la volée
Forcer la sauvegarde	Ctrl+S	Sauvegarder immédiatement dans Drive

Astuce pratique: utilisez des titres de niveau H2/H3 dans vos cellules Markdown pour alimenter la table des matières et faciliter la navigation de toute l’équipe lors des revues.

Démarrage: créer et exécuter un notebook

Mise en route rapide pour que l’équipe produise dès la première session. Suivez ces étapes et lancez vos premières cellules en quelques minutes, en veillant à exécuter le notebook du haut vers le bas pour garder un état cohérent.

1. Créez un notebook: dans Google Drive, cliquez sur “+ Nouveau” > Plus > Google Colaboratory, ou ouvrez Colab et choisissez “New Notebook”. Le fichier est stocké par défaut dans le dossier “Colab Notebooks” de votre Drive.
2. Renommez le fichier, intitulé par défaut Untitled0.ipynb, pour que l’équipe s’y retrouve facilement.
3. Partagez-le à vos équipiers avec les droits d’éditeur. ⚠️ Avertissement: le notebook peut être exécuté par une seule personne à la fois.
4. Exécutez votre première cellule: saisissez un test minimal puis validez.

   print("Hello, Colab")

   Appuyez sur Shift+Entrée pour lancer la cellule. La première exécution initialise l’environnement et peut prendre quelques secondes.
5. Installez vos dépendances au besoin, directement dans une cellule.

   !pip install pandas
   import pandas as pd

6. Accédez à vos fichiers sur Drive si vous travaillez avec des jeux de données partagés:

   from google.colab import drive
   drive.mount('/content/drive')

   Vous pourrez ensuite lire, par exemple, un CSV depuis /content/drive/My Drive/....
7. Besoin d’accélération matérielle pour le machine learning: dans le menu Runtime/Exécution, changez le type d’exécution et sélectionnez un GPU ou un TPU si disponible pour votre compte.
8. Avant un run global, vérifiez l’ordre des cellules: corrigez les dépendances, puis utilisez “Exécution > Exécuter tout”. En cas d’erreurs liées à l’état, redémarrez l’exécution et relancez proprement depuis le début.

Comment fonctionnent cellules et exécution ?

Un notebook Colab alterne des cellules de code et des cellules de texte Markdown. L’état d’exécution vit en mémoire tant que la session reste connectée, donc l’ordre d’exécution compte. Si vous modifiez une cellule utilisée plus haut, relancez les cellules dépendantes pour éviter des incohérences.

Problèmes fréquents: exécuter des cellules dans le désordre, oublier qu’un redémarrage efface variables et imports, installer des bibliothèques dans plusieurs cellules avec des versions différentes, ou relancer une portion de notebook sans réexécuter l’étape d’installation/préparation.

Exemple concret: la cellule B utilise une variable définie en A. Si vous exécutez B avant A, vous obtenez une erreur (NameError). Solution: exécuter A, puis B, ou utiliser “Exécuter tout” après un redémarrage pour repartir d’un état propre.

• Exécuter la cellule courante: Shift+Entrée
• Exécuter sans passer à la suivante: Ctrl+Entrée
• Exécuter et insérer une nouvelle cellule en dessous: Alt+Entrée
• Ajouter une cellule: cliquez sur “+ Code” ou “+ Texte” dans la barre d’outils
• Interrompre ou redémarrer l’environnement: menu Runtime/Exécution
• Consulter l’ensemble des raccourcis: Outils > Raccourcis clavier

Où se trouvent les commandes essentielles ?

Au quotidien, retenez ces points d’entrée: ils couvrent l’exécution, le redémarrage, le choix de l’accélérateur et la gestion des fichiers.

• Lancer toutes les cellules: Runtime/Exécution > Exécuter tout (vérifiez l’ordre avant)
• Interrompre puis redémarrer: Runtime/Exécution > Interrompre, puis Redémarrer
• Choisir l’accélérateur: Runtime/Exécution > Modifier le type d’exécution, puis GPU/TPU (voir GPU et TPU)
• Ouvrir/enregistrer: Fichier > Ouvrir un notebook, Enregistrer une copie dans Drive
• Gérer les fichiers: panneau “Fichiers” à gauche (téléverser, télécharger, créer un dossier)
• Accéder à Drive: panneau “Fichiers” > Monter Drive, ou via from google.colab import drive; drive.mount('/content/drive')
• Console rapide: préfixez par ! dans une cellule (!ls, !pip install paquet)
• Raccourcis: Outils > Raccourcis clavier pour accélérer vos flux

Besoin	Où cliquer	Astuce / raccourci
Lancer toutes les cellules	Runtime/Exécution > Exécuter tout	Vérifiez l’ordre d’exécution avant un run global
Interrompre / redémarrer l’exécution	Runtime/Exécution > Interrompre, puis Redémarrer	Utile si une cellule boucle indéfiniment
Choisir l’accélérateur	Runtime/Exécution > Modifier le type d’exécution, puis GPU/TPU	GPU et TPU accélèrent l’entraînement
Ouvrir / enregistrer	Fichier > Ouvrir un notebook, Enregistrer une copie dans Drive	Les notebooks sont des fichiers .ipynb stockés sur Drive
Gérer les fichiers	Panneau “Fichiers” à gauche: téléverser, télécharger, nouveau dossier	Glisser-déposer possible depuis votre poste
Accéder à Google Drive	Panneau “Fichiers” > Monter Drive, ou cellule Python	from google.colab import drive; drive.mount('/content/drive')
Console/Terminal	Depuis une cellule de code, préfixez vos commandes par !	Exemples: !ls, !pip install nom_paquet
Raccourcis clavier	Outils > Raccourcis clavier	Gagnez du temps dès la première session

Runtimes et accélérateurs (CPU/GPU/TPU)

Dès le démarrage du projet, choisissez le type de runtime dont votre équipe a besoin, puis gardez le même réglage tout au long du travail. Ce choix conditionne les bibliothèques, la mémoire disponible, la stabilité des sessions et le temps d’exécution. En contexte collaboratif, rappelez‑vous qu’un notebook Colab ne peut être exécuté que par une seule personne à la fois, ce qui impose d’anticiper la planification des séances d’entraînement ou d’inférence lourdes.

En pratique, le CPU convient aux tâches de préparation et d’exploration, tandis qu’un GPU ou un TPU accélère fortement l’entraînement de modèles profonds et, selon les cas, l’inférence. Colab gratuit donne accès à des GPU et des TPU selon disponibilité, et les offres Pro et Pro+ donnent un accès prioritaire à des accélérateurs plus rapides et à davantage de mémoire avec des exécutions en arrière‑plan plus longues.

Comment activer GPU/TPU ?

1. Ouvrez votre notebook Colab, puis allez dans le menu Exécution > Modifier le type d’exécution.
2. Dans Accélérateur matériel, choisissez GPU ou TPU, puis validez.
3. Reconnectez l’environnement si Colab vous le propose.
4. Vérifiez la disponibilité de l’accélérateur avec un test rapide.

Tests rapides dans une cellule de code :

GPU, contrôle système

GPU, PyTorch

GPU, TensorFlow

TPU, TensorFlow (initialisation et détection)

Exemple d’utilisation: si votre équipe entraîne un modèle CNN avec PyTorch, activez GPU au préalable, vérifiez torch.cuda.is_available(), puis lancez l’entraînement. Pour TensorFlow sur TPU, sélectionnez TPU, exécutez l’initialisation ci‑dessus et créez votre modèle sous une stratégie TPUStrategy.

CPU, GPU ou TPU: que choisir ?

Tâche	CPU	GPU	TPU	Conseil
Préparation de données, EDA, Pandas, NumPy	Idéal	Peu utile	Non adapté	Restez sur CPU, optimisez l’E/S et l’échantillonnage.
ML classique (scikit‑learn, XGBoost petits jeux)	Très bien	Optionnel	Non adapté	CPU suffit souvent, GPU possible pour XGBoost GPU selon taille.
Deep learning entraînement (vision, NLP, audio)	Lent	Recommandé	Recommandé si TF/JAX	Choisissez GPU pour PyTorch; TPU pertinent pour TensorFlow/JAX et gros batchs.
Affinage léger/LoRA de modèles	Limité	Recommandé	Possible selon lib	Privilégiez un GPU avec VRAM suffisante.
Inférence temps réel petits modèles	Souvent suffisant	Latence plus faible	Peu courant	CPU si contraintes faibles; GPU si débit ou latence importants.
Inférence LLM moyens à grands	Souvent insuffisant	Recommandé	Possible selon stack	GPU conseillé, quantification et batching utiles.
Recherche d’hyperparamètres	OK pour tâches légères	Utile	Utile	Parallélisez, choisissez l’accélérateur du modèle sous‑jacent.
Vision/NLP entraînement long	Trop lent	Très recommandé	Très recommandé si TF/JAX	Planifiez des sessions longues avec Colab Pro/Pro+ ou un runtime local dédié.
Visualisation, rapports	Idéal	Inutile	Inutile	CPU, soignez la mise en cache.

En synthèse: démarrez sur CPU pour l’exploration et la préparation, puis basculez vers GPU pour l’entraînement profond ou une inférence à faible latence. En TensorFlow ou JAX, testez TPU si vous travaillez avec des modèles et des batchs conséquents. Choisissez et verrouillez ce runtime en début de projet pour éviter les ruptures de compatibilité entre coéquipiers, et ajoutez au notebook une cellule de vérification automatique de l’accélérateur afin de détecter rapidement les indisponibilités.

Connecter un runtime local: quand et comment ?

Utile quand: vous devez utiliser un environnement conda local déjà validé par votre équipe, accéder à des données privées en réseau interne, exploiter un GPU local ou une VM privée, ou encore enchaîner des jobs longs hors quotas Colab. Le notebook reste dans Drive, mais l’exécution se fait sur votre machine ou votre VM.

1. Préparer le runtime local
   Option A, image Docker Colab proche des environnements hébergés:

   docker run -p 127.0.0.1:9000:8080 us-docker.pkg.dev/colab-images/public/cpu-runtime
   # Avec GPU (NVIDIA drivers + NVIDIA Container Toolkit requis)
   docker run --gpus=all -p 127.0.0.1:9000:8080 us-docker.pkg.dev/colab-images/public/runtime

   Option B, serveur Jupyter existant:

   jupyter notebook \
     --NotebookApp.allow_origin='https://colab.research.google.com' \
     --port=8888 --NotebookApp.port_retries=0 \
     --NotebookApp.allow_credentials=True

   Conservez l’URL avec le token affiché en sortie, elle sera collée à l’étape 2.
2. Relier Colab à ce runtime
   Dans Colab, cliquez sur le bouton “Connecter”, puis “Se connecter à un runtime local…”. Renseignez l’URL affichée à l’étape précédente et validez.
3. VM distante ou cloud privé
   Établissez un tunnel SSH vers la VM, puis connectez‑vous au port local:

   gcloud compute ssh --zone VOTRE_ZONE VOTRE_VM -- -L 8888:localhost:8888

   Ensuite, collez http://127.0.0.1:8888/?token=... dans la boîte de dialogue “Se connecter à un runtime local…”.
4. Bonnes pratiques
   Versionnez votre environment.yml ou requirements.txt, créez un dossier /content dans le répertoire de travail du serveur Jupyter si vous utilisez les fonctions de gestion de fichiers de Colab, et limitez l’accès au notebook si des données sensibles sont traitées.

Référence utile: la documentation officielle sur les runtimes locaux Colab. Pour l’initialisation TPU sous TensorFlow, consultez le guide Use TPUs.

Système de fichiers et persistance: que faut‑il savoir ?

Dans Colab, l’environnement d’exécution est temporaire: il se réinitialise régulièrement. Les fichiers créés localement, les bibliothèques installées et les caches disparaissent lors d’un redémarrage. Conséquence directe, il faut versionner le code et automatiser l’installation des dépendances, puis choisir un espace de stockage persistant pour ne pas perdre ses données et ses modèles.

Emplacement	Nature	Persistance	Usage recommandé
/content (VM Colab)	Éphémère	Non: effacé à la fin de session	Travail temporaire, tests rapides, caches courts
/content/drive/... (Google Drive monté)	Persistant	Oui: fichiers conservés sur votre Drive	Jeux de données partagés d’équipe, outputs à conserver
GitHub (repo)	Persistant	Oui: versionnement du code	Code, notebooks, requirements.txt
Google Cloud Storage (GCS)	Persistant	Oui: stockage d’objets	Fichiers volumineux, données brutes, modèles
BigQuery	Persistant	Oui: entrepôt de tables	Données tabulaires, SQL, jointures à l’échelle
Sorties dans le notebook .ipynb	Persistant si enregistré	Oui: via Drive	Résultats légers, graphiques, traces d’exécution

Espace /content éphémère: que disparaît‑il ?

/content correspond au disque local de la machine virtuelle attachée à votre session. Il est recréé fréquemment. Tout ce qui s’y trouve est détruit quand l’environnement est redémarré, inactif trop longtemps, déconnecté, ou quand vous changez d’accélérateur (CPU/GPU/TPU).

• Fichiers et dossiers créés dans /content (données téléchargées, modèles entraînés, artefacts).
• Installations via %pip et apt-get réalisées pendant la session.
• Caches sous /root/.cache et similaires (pip, datasets, modèles).
• Variables d’environnement et montages temporaires.

Conséquences: sauvegardez systématiquement les sorties importantes vers un stockage persistant, remontez Drive à chaque nouvelle session si besoin, et placez une cellule “setup” au début du notebook pour réinstaller proprement les dépendances.

Où sauvegarder durablement (Drive, GCS, GitHub) ?

Option	Ce qui persiste	Avantages	Limites	Accès depuis Colab
Google Drive	Fichiers et dossiers partagés	Simplicité, partage fin, intégré à Colab	Moins adapté aux très gros volumes	from google.colab import drive; drive.mount('/content/drive')
Google Cloud Storage (GCS)	Objets dans des buckets	Échelle, performance, contrôle IAM	Nécessite un projet Cloud et auth	gsutil ou SDK Python Storage
BigQuery	Tables colonnes	SQL, jointures massives, gouvernance	Pas de stockage de fichiers bruts	Magics BigQuery %%bigquery ou client Python
GitHub	Code, notebooks, configs	Versionnement, revues, CI	Pas fait pour données volumineuses	!git clone ... ou ouverture directe du notebook

En pratique: gardez le code et requirements.txt sur GitHub, stockez les petits jeux de données d’équipe sur Drive, déplacez les gros fichiers et modèles vers GCS, et mettez les tables analytiques dans BigQuery. Vous combinez ainsi simplicité, performance et traçabilité.

Quotas de disque et cache: bonnes pratiques

• Mesurer l’espace et chasser les gros dossiers: !df -h, !du -sh /content/* | sort -h.
• Sauvegarder tôt et souvent: écrivez les artefacts importants vers /content/drive/... ou vers GCS au fil de l’eau.
• Nettoyer les caches inutiles: !pip cache purge, suppression ciblée dans /root/.cache après sauvegarde des éléments utiles.
• Compresser avant transfert: !zip -9 -r sortie.zip dossier/ réduit la place et accélère la copie vers Drive ou GCS.
• Échantillonner et streamer: pour les CSV volumineux, lisez par morceaux (chunksize) plutôt que de tout charger en mémoire.
• Éviter les duplications: centralisez les données partagées sur Drive ou GCS, référencez‑les par un chemin commun.
• Ne pas écrire dans le système: limitez‑vous à /content et au montage Drive pour éviter des conflits et faciliter le nettoyage.

Astuce d’équipe: ajoutez une cellule “maintenance” en fin de notebook pour déclencher en un clic la sauvegarde des résultats, le nettoyage des caches et l’affichage du bilan d’espace disque, puis vérifiez la présence des fichiers attendus dans Drive ou GCS avant de fermer la session.

Dépendances et environnement: comment faire ?

Problème fréquent en équipe: chacun lance le notebook, mais n’a pas les mêmes bibliothèques ni les mêmes versions. Résultat, des erreurs difficiles à reproduire. L’objectif est de rendre l’environnement reproductible pour toute l’équipe en séparant clairement dépendances Python et paquets système, en vérifiant la compatibilité CUDA/frameworks pour le GPU et en figeant les versions dans un fichier partagé.

• Centraliser l’installation dans une cellule “setup” au début du notebook.
• Distinguer bibliothèques Python et dépendances système.
• Contrôler l’alignement CUDA ↔ PyTorch/TensorFlow quand vous utilisez un GPU.
• Figer et partager les versions via un requirements.txt commun et versionné.

Installer des paquets Python: %pip ou pip ?

Sur Colab, utilisez le magic %pip plutôt que !pip pour installer vos bibliothèques. %pip garantit que l’environnement Python du kernel est mis à jour correctement, ce qui évite des incohérences entre l’interpréteur et les paquets installés.

• Installez en une seule cellule en début de notebook, avec des versions explicites: %pip -q install pandas==2.2.2 scikit-learn==1.5.0.
• Évitez d’étaler les installations sur plusieurs cellules, source de conflits.
• Après une installation lourde, redémarrez le runtime si Colab le suggère.
• Rappelez que l’environnement est éphémère: réinstallez à chaque nouvelle session.

Paquets système: quand utiliser apt-get ?

Réservez apt-get aux dépendances système dont certaines libs Python ont besoin, par exemple des bibliothèques natives pour l’affichage, l’audio ou la vidéo. Installez uniquement le nécessaire, sans mise à jour globale du système.

• Exemples utiles: libgl1 ou libgl1-mesa-glx pour OpenCV, ffmpeg pour le traitement vidéo, libsndfile1 pour l’audio.
• Commande type: !apt-get -y update && apt-get -y install libgl1-mesa-glx ffmpeg.
• Limites: rallonge du temps de démarrage, parfois besoin de redémarrer le runtime.
• Persistance: rien n’est conservé entre deux sessions, prévoyez une cellule “setup” idempotente.
• À éviter: upgrade ou dist-upgrade qui peuvent casser l’image Colab.

CUDA/TF/PyTorch: quelles versions compatibles ?

Principe: alignez la version CUDA disponible dans Colab avec les roues des frameworks. Commencez par détecter l’accélérateur et sa version, puis installez les paquets correspondants.

CUDA visible dans Colab	PyTorch: balise du wheel	TensorFlow/JAX conseillé	Installation type
11.8	cu118	tensorflow standard ou existant dans l’image	%pip install --index-url https://download.pytorch.org/whl/cu118 torch torchvision torchaudio
12.1	cu121	tensorflow récent, vérifier la détection GPU	%pip install --index-url https://download.pytorch.org/whl/cu121 torch torchvision torchaudio
12.4	cu124	tensorflow récent, vérifier la détection GPU	%pip install --index-url https://download.pytorch.org/whl/cu124 torch torchvision torchaudio
TPU	Non applicable	TensorFlow avec TPUStrategy ou JAX sur TPU	Activez TPU dans Exécution > Modifier le type d’exécution, puis initialisez la stratégie dans le code
CPU uniquement	cpu	tensorflow-cpu si besoin	%pip install --index-url https://download.pytorch.org/whl/cpu torch torchvision torchaudio

Vérifications rapides:

• !nvidia-smi pour voir le GPU et la version CUDA du runtime.
• PyTorch: import torch; torch.cuda.is_available(), torch.version.cuda.
• TensorFlow: import tensorflow as tf; tf.config.list_physical_devices('GPU') ou 'TPU'.

Erreurs typiques et pistes:

• CUDA error: invalid device function ou CUDA driver mismatch: la roue PyTorch ne correspond pas à la version CUDA du runtime. Réinstallez avec la bonne balise cuXXX.
• Could not load libcudnn: dépendance manquante ou version incompatible. Mettez à jour le framework depuis une roue officielle adaptée au CUDA du runtime.
• TensorFlow ne voit pas le GPU: vérifiez le type d’exécution, réinstallez tensorflow, puis redémarrez le runtime.

Comment figer et partager l’environnement (requirements.txt) ?

1. Listez vos dépendances directes dans un fichier requirements.in avec un pinning strict quand la reproductibilité est clé, par exemple pandas==2.2.2 ou tolérant avec ~= si vous acceptez les correctifs.
2. Générez un lock file reproductible avec pip‑tools: %pip install -q pip-tools puis pip-compile -q --generate-hashes -o requirements.txt requirements.in.
3. Installez exactement ces versions dans Colab: %pip -q install -r requirements.txt ou pip-sync -q requirements.txt.
4. Versionnez requirements.in et requirements.txt dans le repo du projet ou un dossier Drive partagé, et réutilisez-les en CI.
5. Pour les équipes: regroupez d’éventuels artefacts (ex. roues privées) dans un dossier dédié du projet ou un index privé si vous en avez un, et documentez la procédure d’update via PR.

Pratique: dans un notebook Colab, vous pouvez régénérer le requirements.txt à partir d’un environnement propre, le déposer dans Drive puis l’installer en début de session avec %pip -q install -r "/content/drive/My Drive/projet/requirements.txt".

Peut-on utiliser conda ou un runtime local ?

Conda n’est pas présent par défaut sur Colab. L’option la plus simple et robuste pour un notebook partagé reste pip + requirements.txt. Vous pouvez installer un gestionnaire d’environnements dans une cellule, par exemple micromamba pour créer un environnement minimal. Intérêt: résolution rapide des dépendances. Limites: temps d’installation initial, possible redémarrage du kernel, surcoût de complexité pour l’équipe.

Quand préférer un runtime local ou une VM: si vous avez besoin d’un environnement persistant, de versions système précises, d’un pilote CUDA spécifique, d’un accès réseau particulier ou de données volumineuses. Vous pouvez connecter l’interface Colab à un runtime local pour garder le confort du notebook tout en exécutant sur votre machine ou une VM configurée par l’équipe.

Commandes utiles et magics Colab

Pour gagner du temps et diagnostiquer vite, Colab permet d’exécuter des commandes système directement depuis une cellule, et d’utiliser les magics IPython pour configurer et automatiser l’exécution. Rappel utile déjà vu plus haut: depuis une cellule de code, préfixez vos commandes par ! pour le shell, et privilégiez %pip à !pip pour installer des bibliothèques Python.

Comment exécuter des commandes shell (!, %%bash) ?

Deux options simples: une commande unique avec !, ou un script multi‑lignes avec le cell magic %%bash. Pratique pour gérer des fichiers, télécharger des données, ou installer des paquets système quand c’est nécessaire pour une bibliothèque Python.

Exemples rapides:

• Lister les fichiers du répertoire de travail /content:

  !ls -lah

• Télécharger un fichier public:

  !wget -q https://example.com/data.csv -O data.csv
  !head -n 5 data.csv

• Installer un paquet système requis par une lib Python:

  !apt-get -y update
  !apt-get -y install libgl1-mesa-glx

• Script shell multi‑lignes avec %%bash:

  %%bash
  set -e
  echo "Préparation dossier..."
  mkdir -p /content/work
  echo "Version Python:"
  python -V

• Rappel bonnes pratiques déjà abordées: gardez les installations Python dans une cellule unique avec %pip, réservez apt-get aux dépendances système, et évitez les mises à jour massives.

Magics pratiques (%env, %%capture, %load_ext)

• %env définir et lire des variables d’environnement pour tout le runtime:

  %env DATA_DIR=/content/drive/My\ Drive/projet/data
  import os
  os.getenv("DATA_DIR")

• %%capture exécuter une cellule en silence et capturer la sortie, utile pour rendre le notebook plus lisible:

  %%capture cap
  %pip -q install seaborn==0.13.2
  
  # Plus tard, afficher la sortie si besoin
  # cap.show()

• %load_ext charger des extensions IPython pour ajouter des fonctionnalités:

  %load_ext autoreload
  %autoreload 2  # recharge automatiquement les modules importés
  
  # Exemple: recharger un module local stocké sur Drive
  from google.colab import drive
  drive.mount('/content/drive')
  import sys
  sys.path.append('/content/drive/My Drive/projet/src')
  import utils  # se rechargera après chaque exécution grâce à %autoreload

Astuce: combinez %env pour paramétrer des chemins communs à l’équipe, %%capture pour réduire le bruit des installations, et %load_ext autoreload pour itérer vite sur vos modules partagés.

Diagnostics rapides (nvidia-smi, free, top)

Sans outils externes, vérifiez en quelques secondes l’état du GPU, de la RAM, du CPU et de l’espace disque. Ces commandes s’exécutent dans une cellule avec !. Elles sont particulièrement utiles en début de session ou quand une cellule devient lente.

• GPU, seulement si un GPU est alloué dans Exécution > Modifier le type d’exécution:

  !nvidia-smi -L                   # modèle(s) de GPU
  !nvidia-smi --query-gpu=name,memory.total --format=csv,noheader

  # Côté Python (PyTorch), vérifier la disponibilité:
  import torch
  print(torch.cuda.is_available())
  if torch.cuda.is_available():
      print(torch.cuda.get_device_name(0))

• Mémoire RAM disponible:

  !free -h

• Utilisation CPU en un instantané lisible:

  !top -bn1 | head -n 15

• Espace disque, utile avant d’écrire des sorties volumineuses:

  !df -h

Bon réflexe d’équipe: ajoutez ces diagnostics en haut du notebook pour détecter très tôt une indisponibilité d’accélérateur ou une mémoire trop juste, puis relancez l’exécution complète une fois l’environnement validé.

Importer des données: vos options

Vous travaillez en équipe sur un notebook Colab et vous devez partager des fichiers de données, parfois publics, parfois privés, stockés sur le web, Drive ou le cloud. Voici un panorama pratique, orienté choix, pour importer rapidement vos datasets selon la taille des fichiers, le niveau de confidentialité, la source et la fréquence d’actualisation.

Comment choisir la méthode d’import ?

Tableau mental express: commencez simple, puis montez en puissance. Pour un petit CSV public, préférez BytesIO ou gdown. Pour des données privées d’équipe, un montage Drive avec un chemin commun fait l’affaire. Pour des volumes importants ou des pipelines récurrents, passez au cloud (GCS, BigQuery). Pour un import ponctuel manuel, utilisez google.colab.files.

Contrainte principale	Source	Fréquence	Méthode conseillée
Petit fichier, public	Drive ou URL	Occasionnelle	BytesIO (requests) ou gdown
Plusieurs fichiers, publics	Dossier Drive public	Régulière	gdown (fichier ou dossier)
Fichiers privés d’équipe	Drive partagé	Régulière	Raccourci Drive + drive.mount
Upload/Download à la main	Poste local	Ponctuelle	google.colab.files
URL générique	Web public	Occasionnelle	wget ou curl
Gros volumes/partage stable	Cloud (GCS)	Régulière	gsutil ou SDK Storage
Tables et SQL	BigQuery	Régulière	Magics BigQuery ou SDK
Datasets publics Kaggle	Kaggle	Occasionnelle/Régulière	Kaggle API avec kaggle.json

Scénario 1 : BytesIO avec 1 fichier

Lucas recommande cette méthode en début de projet. Avec elle, le même fichier source peut être utilisé par toute l’équipe, le fichier peut être stocké dans n’importe quel compte, il suffit de le rendre public. Ainsi, chaque membre de l’équipe peut exécuter le notebook sans modifier la cellule de code qui charge le jeu de données.

Exemple minimal avec un CSV public:

🔗 Pour en savoir plus : consultez la documentation sur https://docs.python.org/3/library/io.html.

Scénario 2 : gdown pour fichiers publics

Alia propose régulièrement cette approche aux étudiants qu’elle mentore. La librairie gdown est spécifiquement conçue pour importer des fichiers depuis Google Drive. Là encore, avec cette méthode, le fichier source stocké sur Drive doit être rendu public. Astuce : le paramètre quiet=True supprime la sortie de progression pendant le téléchargement, le rendant moins verbeux.

🗃️ Vous avez plusieurs fichiers à importer ? gdown permet aussi d’importer un dossier Drive et son contenu en bloc, avant d’ouvrir le ou les jeux de données qui vous intéressent.

Exemples rapides:

🔗 Pour en savoir plus : la documentation est accessible sur https://pypi.org/project/gdown et notre script reprend la démo proposée par Google Colab à la page exemple d’utilisation.

Scénario 3 : Raccourci Drive pour fichiers privés

Vos fichiers sources doivent rester privés ? Vous pouvez partager un notebook à votre équipe et l’exécuter à tour de rôle pour analyser un jeu de données partagé uniquement aux autres membres. Le mode opératoire qui suit vise à harmoniser le chemin d’accès aux fichiers, pour que chaque membre soit en mesure d’exécuter la même cellule d’importation des datasets en début de notebook.

Exemple simple avec trois utilisateurs A, B et C:

1. A dépose le jeu de données data.csv dans un dossier Data à la racine de son Drive, puis partage ce dossier avec B et C en lecture ou édition selon besoin.
2. Chaque membre crée dans son “Mon Drive” un dossier de travail commun, par exemple projet_fil_rouge, et y ajoute un raccourci vers le dossier Data partagé (clic droit > “Ajouter un raccourci à Drive”). Le nom du raccourci doit être identique pour tous, par exemple data_shared.
3. Dans Colab, on monte Drive et on pointe vers le même chemin logique pour tous.

Droits et performances: évitez les liens publics, gardez des partages Drive restreints. La lecture directe depuis Drive est pratique mais plus lente que le disque local; pour des entraînements répétés, copiez d’abord le fichier dans /content puis travaillez sur cette copie temporaire.

Monter Google Drive: quand et comment ?

1. Montez Drive quand vous avez des fichiers partagés d’équipe ou un artefact à persister entre sessions: from google.colab import drive; drive.mount('/content/drive').
2. Standardisez les chemins: définissez une variable ROOT = "/content/drive/My Drive/projet_fil_rouge", puis utilisez ROOT + "/data/...".
3. Structurez votre dépôt: data/ pour les jeux légers, notebooks/, outputs/. Placez les gros volumes sur GCS.
4. Évitez d’écrire en boucle sur Drive pendant un entraînement. Préférez écrire localement dans /content, puis synchroniser à la fin.
5. Nettoyez les chemins “hardcodés”: regroupez l’import et la configuration des chemins dans une seule cellule en haut du notebook.

Bonne pratique: ajoutez une cellule de vérification qui teste l’existence des chemins attendus et affiche un message d’aide en cas d’erreur d’accès.

Quand utiliser google.colab.files ?

Utile pour un transfert manuel ponctuel depuis votre poste, par exemple pour déposer un petit CSV privé ou récupérer un résultat localement. Non adapté à l’automatisation ni aux gros volumes.

Sécurité: ne chargez pas de secrets en clair. Préférez un fichier secrets.json chiffré ou un stockage cloud avec ACL strictes. Les fichiers uploadés ne survivent pas à la fin de session si non sauvegardés sur Drive.

wget/curl: comment télécharger depuis le web ?

• Scriptable et répétable: intégrez vos téléchargements dans des cellules, versionnez les URLs.
• Suivez les redirections et nommez le fichier de sortie.
• Vérifiez l’intégrité via un checksum quand c’est possible.
• Gérez les archives pour éviter l’encombrement.

Google Cloud Storage/BigQuery: quand les utiliser ?

Pour des datasets volumineux, des accès multi‑équipes et une authentification sécurisée, utilisez Google Cloud Storage pour les fichiers et BigQuery pour les tables. Avantages: contrôle d’accès fin, performance, coût maîtrisé grâce au stockage et au calcul séparés.

• Cas typiques: données brutes en gs://, feature store en Parquet, tables analytiques dans BigQuery, notebooks Colab pour l’exploration.
• Accès sécurisé: authentifiez‑vous, puis utilisez gsutil, les clients Python ou les magics BigQuery.

Kaggle: comment s’authentifier ?

1. Générez un token API depuis votre profil Kaggle, téléchargez kaggle.json.
2. Chargez‑le dans Colab, placez‑le dans ~/.kaggle/ avec les bons droits.
3. Téléchargez le dataset ou la compétition voulue, puis décompressez.

Conséquences pratiques: ne commitez jamais kaggle.json dans un dépôt. Stockez‑le de préférence sur Drive dans un dossier à accès restreint. Certains jeux exigent l’acceptation de conditions d’usage côté Kaggle avant de pouvoir les télécharger.

Lire depuis une base SQL ou une API REST: comment faire ?

Pour les bases SQL, utilisez SQLAlchemy avec des identifiants stockés en variables d’environnement. Pour les API, gérez l’authentification, la pagination et le throttling.

• Secrets: ne les mettez pas en clair dans le notebook. Chargez‑les depuis un fichier chiffré ou des variables d’environnement stockées sur Drive à accès restreint.
• Robustesse: implémentez des retries exponentiels, vérifiez les quotas, tracez les appels.
• Schéma: documentez les colonnes/contrats d’API et validez les données à l’ingestion.

Gros volumes: streaming et formats efficaces (Parquet, tf.data)

Sur des datasets lourds, évitez les copies complètes en mémoire. Préférez les lectures en flux, les itérateurs et des formats colonnes comme Parquet. Pour l’entraînement, exploitez tf.data et le préchargement asynchrone.

• Pandas en streaming: lisez par morceaux et concaténez au besoin.
• Parquet: colonnes compressées, lecture sélective des champs, compatible GCS.
• Cache local: copiez une seule fois depuis GCS vers /content, puis réutilisez.
• TensorFlow: utilisez des pipelines tf.data avec prefetch et AUTOTUNE.

Authentification et permissions

Travailler en équipe sur Colab implique de bien maîtriser l’accès aux données et aux APIs Google. Entre OAuth pour Google Drive, comptes de service côté entreprise et accès GCP via la CLI, voici les repères pratiques pour sécuriser et fluidifier vos workflows.

Comment fonctionne l’OAuth et les scopes Drive ?

Colab utilise OAuth pour autoriser un notebook à accéder à votre Drive ou à des APIs Google Cloud. La première exécution affiche une fenêtre d’autorisation, puis un jeton est stocké pour la session active du runtime. À chaque redémarrage d’environnement, il peut être nécessaire de ré‑authentifier.

• Principe: vous autorisez explicitement le notebook à agir en votre nom. En Python, from google.colab import drive; drive.mount('/content/drive') déclenche l’autorisation d’accès à Drive.
• Scopes minimaux: lorsque vous utilisez les SDK Google, demandez le strict nécessaire, par exemple lecture seule plutôt que lecture/écriture. Exemples courants: https://www.googleapis.com/auth/drive.readonly, https://www.googleapis.com/auth/drive.file, ou https://www.googleapis.com/auth/drive si vraiment requis.
• Fenêtres d’authentification: validez l’accès lors du premier appel. En contexte BigQuery ou autres APIs GCP, utilisez from google.colab import auth; auth.authenticate_user().
• Refresh et revoke: les jetons expirent et peuvent être révoqués depuis les paramètres de votre compte Google. Si des droits changent côté Drive, relancez l’authentification pour prendre en compte les nouveaux périmètres.
• Bonnes pratiques d’équipe: affichez le chemin d’accès commun en début de notebook et validez que l’utilisateur est bien authentifié avant de charger les données.

Service accounts : utiles en entreprise ?

Un compte utilisateur OAuth est idéal pour l’exploration interactive, les revues et les notebooks partagés. Un service account convient mieux aux usages d’équipe et aux automatisations, car il ne dépend pas d’une personne et peut recevoir des rôles IAM précis sur des ressources ciblées.

• Cas individuels: exploration ponctuelle d’un dossier Drive ou lecture depuis BigQuery. Préférez OAuth utilisateur, pas de clé à gérer.
• Cas service/équipe: jobs récurrents, notebooks d’onboarding qui doivent lire un bucket GCS commun ou écrire dans un dataset BigQuery du projet. Créez un compte de service avec rôles minimaux sur le bucket ou le dataset concernés.
• Partage sécurisé de clés: évitez d’inclure un key.json dans le repo ou dans un notebook. Si la clé est incontournable, stockez‑la dans un espace restreint, chiffrez au repos, limitez sa durée de vie, pivotez les clés régulièrement et journalisez les accès. Mieux encore, privilégiez l’authentification utilisateur ou des environnements managés sur Google Cloud quand c’est possible.

Cas concret: une équipe doit lire des fichiers dans gs://projet‑data/lake/raw et écrire des tables dans bigquery:projet_analytics.mart_*. Créez un service account [email protected] avec les rôles minimaux, par exemple Storage Object Viewer sur le bucket précis et BigQuery Data Editor sur le dataset cible. Chargez la clé uniquement au moment de l’exécution, puis supprimez‑la de l’instance Colab à la fin de la session.

Mon Drive ou Drive partagé : que choisir ?

Critère	Mon Drive	Drive partagé	Conseil projet
Propriété	Appartient à l’utilisateur	Appartient à l’équipe/organisation	Évitez la dépendance à une personne
Offboarding	Risque de perte si l’utilisateur part	Accès géré par groupes	Privilégiez les Drives partagés
Permissions	Partage au fichier/dossier	Rôles d’équipe cohérents	Attribuez par groupes IAM/Google Group
Gouvernance	Hétérogène	Politiques homogènes par espace	Séparez par projet ou produit
Liens et stabilité	Liens moins pérennes	Meilleure stabilité des accès	Référencez un chemin commun
Partage externe	Facile mais risqué	Paramètres contrôlés par admin	Bloquez le public pour données sensibles

En synthèse: gardez vos notebooks personnels dans Mon Drive si nécessaire, mais placez les données d’équipe dans un Drive partagé dédié par projet. Utilisez des groupes pour attribuer les rôles, documentez les chemins et évitez les liens publics non maîtrisés.

Accès GCP (gcloud auth, gcsfuse): quels cas d’usage ?

• Authentification CLI pour SDK et bibliothèques:

  # OAuth utilisateur pour la CLI
  !gcloud auth login --quiet
  
  # Identifiants par défaut pour les SDK Python (ADC)
  !gcloud auth application-default login --quiet
  

  Utilisez application-default quand vos notebooks emploient google-cloud-* en Python.
• Transferts simples de fichiers GCS:

  !gsutil -m cp gs://projet-data/lake/raw/*.csv /content/data/
  !gsutil -m cp /content/exports/*.parquet gs://projet-data/exports/

  Pratique pour des lots ponctuels et reproductibles dans une cellule.
• Montage d’un bucket avec gcsfuse pour travailler comme sur un dossier:

  !apt-get -y update && apt-get -y install gcsfuse
  !mkdir -p /content/gcs/bucket
  !gcsfuse --implicit-dirs projet-data /content/gcs/bucket
  !ls /content/gcs/bucket

  Utile pour parcourir des hiérarchies de fichiers. Évitez les milliers de petits fichiers, privilégiez dans ce cas gsutil ou un chargement direct via SDK.
• BigQuery depuis Colab:

  from google.colab import auth
  auth.authenticate_user()
  
  from google.cloud import bigquery
  client = bigquery.Client()
  df = client.query("SELECT COUNT(*) as n FROM `projet.dataset.table`").to_dataframe()

  Simple pour explorer des tables d’équipe avec des identifiants utilisateur.
• Implications de sécurité:
  • Ne stockez pas de clés dans le notebook ou le repo. Si une clé de service est utilisée, chargez‑la depuis un emplacement chiffré, supprimez‑la après usage et restreignez ses rôles.
  • Appliquez le moindre privilège sur GCS et BigQuery, préférez les groupes à des partages individuels.
  • Révoquez l’accès avec !gcloud auth revoke si nécessaire et auditez régulièrement les permissions.
  Se former à IAM et à Google Cloud pour sécuriser vos notebooks

  Collaboration, sauvegarde et versioning

  Pour travailler en équipe à distance, un notebook Colab se partage comme un document Google Docs, tout en restant un fichier .ipynb stocké sur Drive. Gardez en tête qu’un même notebook ne peut être exécuté activement que par une personne à la fois, ce qui impose des règles d’organisation. L’objectif: un flux où GitHub centralise le code et l’historique, Drive héberge les données partagées et les artefacts, le tout sans doublons inutiles.

  Partage et historique des révisions: que permet Colab ?

  Colab s’appuie sur Google Drive pour le stockage, les droits et l’historique. Vous contrôlez qui peut lire, commenter ou éditer, vous ouvrez des fils de commentaires directement sur des cellules, et vous consultez les versions précédentes du fichier pour revenir en arrière si besoin.

  • Droits de partage: attribuez Lecteur, Commentateur ou Éditeur, limitez l’accès par e‑mail ou domaine, désactivez le partage de lien public si les données sont sensibles.
  • Commentaires et mentions: sélectionnez une zone dans une cellule de texte ou de code, ajoutez un commentaire, mentionnez un coéquipier avec @ pour lui attribuer une action, résolvez les fils quand c’est traité.
  • Historique de versions: Drive conserve l’historique d’un .ipynb. Renommez une version clé, comparez, restaurez si nécessaire. Pratique avant une refactorisation majeure.
  • Limite d’exécution: une seule session active par notebook, planifiez les entraînements lourds ou travaillez par duplicats temporaires puis fusionnez.

  Comment ouvrir depuis GitHub et pousser vos changements ?

  1. Ouvrir depuis GitHub: dans Colab, utilisez Fichier > Ouvrir un notebook puis l’onglet GitHub. Collez l’URL du repo ou du notebook .ipynb, sélectionnez la branche et le fichier.
  2. Cloner un dépôt pour travailler côté fichiers: exécutez git clone dans une cellule, puis naviguez dans le dossier.

     !git clone https://github.com/organisation/projet.git
     %cd projet

  3. S’authentifier pour pousser: créez un token d’accès personnel GitHub, puis configurez Git et utilisez une URL avec token ou une invite sécurisée.

     !git config --global user.email "[email protected]"
     !git config --global user.name "Votre Nom"
     # Méthode simple, évitez de consigner le token en clair dans le notebook
     !git remote set-url origin https://<TOKEN>@github.com/organisation/projet.git

  4. Notebooks vs scripts: pour un .ipynb ouvert via l’onglet GitHub, utilisez Fichier > Enregistrer une copie dans GitHub pour créer une PR rapide. Pour des scripts, modules, données d’exemple, utilisez les commandes Git classiques.

     !git add .
     !git commit -m "MAJ nettoyage sorties + correction import"
     !git push origin ma-branche

  5. Éviter les doublons Drive/GitHub: décidez d’une source de vérité. Recommandation d’équipe: GitHub pour le code et les notebooks, Drive pour les datasets et artefacts volumineux. Interdisez l’édition durable d’une même copie sur Drive et sur GitHub en parallèle.

  Quelles conventions d’équipe adopter pour les notebooks ?

  • Nommage explicite: 01_exploration.ipynb, 02_features.ipynb, 03_modelisation.ipynb. Préfixe numérique pour l’ordre logique, suffixe court pour la tâche.
  • Cellules testables: regroupez l’import, la configuration et les fonctions réutilisées. Ajoutez des assertions rapides ou un bloc de tests minimal pour détecter les régressions.
  • Sorties propres: nettoyez les sorties avant commit pour réduire les diffs. Paramétrez un hook Git type nbstripout ou exécutez un nettoyage dans la CI.
  • Export .py: pour relire en PR, exportez aussi en script lisible ou mettez en place un appairage .ipynb ↔ .py avec un outil comme Jupytext.
  • Idempotence: fixez les graines aléatoires, centralisez l’installation des dépendances au début, évitez les états implicites de session.
  • Modularisation: extrayez les fonctions et modèles communs dans src/, importez‑les depuis les notebooks pour limiter les collisions d’édition.

  En synthèse, traitez les notebooks comme du code: petite taille, étapes claires, sorties épurées, revue par PR et tests rapides pour garantir la reproductibilité d’une session à l’autre.

  Commenter et co‑éditer en temps réel ?

  Le partage Drive permet l’édition conjointe, la revue et la discussion asynchrone directement dans le notebook. Utilisez les mentions, décidez d’une règle de prise de contrôle de l’exécution, et gérez les conflits par branches Git.

  • Mentions et suivis: ouvrez un commentaire sur la cellule concernée, mentionnez @prenom.nom, attribuez et résolvez quand c’est traité.
  • Exécution unique: annoncez sur le canal d’équipe qui “prend” le runtime, sinon dupliquez le notebook pour une exploration parallèle, puis fusionnez via GitHub.
  • Conflits d’édition: évitez de réordonner les cellules sans nécessité, gardez des titres de sections stables, centralisez les changements risqués dans une branche dédiée.
  • Revue: préférez la relecture sur GitHub, plus fiable pour l’historique et la discussion par ligne, surtout si vous avez exporté en .py ou activé un diff de notebooks.

  Exporter en .ipynb, .py, PDF: quelles options ?

  • Depuis l’interface: Fichier > Télécharger > .ipynb ou .py. Pour un PDF rapide, utilisez Imprimer puis “Enregistrer au format PDF”.
  • Avec nbconvert dans une cellule:

    !jupyter nbconvert --to notebook --ClearOutputPreprocessor.enabled=True mon_notebook.ipynb
    !jupyter nbconvert --to html mon_notebook.ipynb
    # PDF requis: LaTeX présent sur l’environnement
    !jupyter nbconvert --to pdf mon_notebook.ipynb

  • Intégration CI: exécutez, nettoyez, vérifiez.

    # Exécuter et échouer si une cellule plante
    !jupyter nbconvert --to notebook --execute --inplace --ExecutePreprocessor.timeout=600 mon_notebook.ipynb
    # Nettoyer les sorties avant commit automatique
    !jupyter nbconvert --to notebook --ClearOutputPreprocessor.enabled=True --inplace mon_notebook.ipynb
    # Export pour artefacts de build
    !jupyter nbconvert --to html mon_notebook.ipynb

  Apprendre à utiliser Python sur Google Colab

  Quelles limites et quotas s’appliquent ?

  Colab alloue des ressources de façon dynamique: les fenêtres de session, l’inactivité, les types de GPU/TPU disponibles, la mémoire et même l’espace disque local varient selon la charge et votre historique d’usage. Google ne publie pas de chiffres fixes, mais donne des bornes et des règles de fonctionnement utiles pour s’organiser en équipe. Gardez aussi en tête qu’un notebook ne peut être exécuté activement que par une seule personne à la fois, et que l’environnement est temporaire, ce qui impose de bien versionner le code et d’automatiser l’installation des dépendances. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  Point clé	Gratuit	Pro	Pro+
  Durée max d’une session interactive	Jusqu’à 12 h selon disponibilité et usage	Jusqu’à 12 h selon disponibilité et solde d’unités	Jusqu’à 12 h selon disponibilité et solde d’unités
  Inactivité	Arrêt si la session devient inactive	Arrêt si la session devient inactive	Arrêt si la session devient inactive
  Exécution en arrière‑plan	Non	Non	Oui, exécution continue jusqu’à 24 h avec unités suffisantes
  Mémoire système	Profil standard	Accès à des machines haute mémoire selon disponibilité	Accès à des machines haute mémoire selon disponibilité
  Accélérateurs	Accès limité selon disponibilité	Accès prioritaire à des GPU premium selon disponibilité	Accès prioritaire à des GPU premium selon disponibilité
  Compute units mensuelles	Pas d’accès garanti	100 unités	500 unités
  Disque local de la VM	Temporaire, remis à zéro	Plus d’espace local que Gratuit	Plus d’espace local que Gratuit
  Stockage Drive	Selon votre quota Drive, distinct du disque de la VM	Idem	Idem

  Références officielles: durée interactive jusqu’à 12 h, exécution en arrière‑plan Pro+ jusqu’à 24 h si vous avez assez de compute units, mémoire haute disponible sur les offres payantes, et compute units mensuelles de 100 (Pro) et 500 (Pro+). Notez aussi que l’achat d’espace sur Drive n’augmente pas la taille du disque local de la VM, qui reste éphémère. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html)) ([support.google.com](https://support.google.com/a/answer/13177581?hl=en))

  Quelle est la durée de session et l’inactivité ?

  Colab privilégie l’exécution interactive: une session s’arrête si elle devient inactive, et la durée maximale d’exécution dépend de la charge et de vos usages. En pratique, comptez jusqu’à 12 heures pour une session interactive, toutes offres confondues. Avec Pro+, vous pouvez lancer des tâches en arrière‑plan jusqu’à 24 heures si votre solde d’unités le permet. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  • Anticiper la déconnexion: sauvegarder automatiquement le notebook sur Drive et enregistrer des checkpoints fréquents.
  • Rendre l’environnement reproductible: cellule “setup” unique qui installe les dépendances, comme décrit plus haut dans l’article.
  • Découper les runs longs en étapes redémarrables, avec reprise depuis Drive ou un stockage cloud.
  • Planifier les entraînements coûteux sur des plages continues, et réserver Pro+ si vous avez besoin d’arrière‑plan jusqu’à 24 h.
  • Besoins au‑delà de ces bornes: passer sur une VM dédiée via Google Cloud Marketplace ou Colab Enterprise pour lever ces limites. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  Quelles limites de RAM et de disque ?

  Mémoire: Colab ne publie pas de tailles fixes. Le palier gratuit donne accès à un profil de mémoire “standard”, et les offres payantes débloquent des machines “haute mémoire” selon disponibilité et votre solde d’unités. La quantité exacte peut varier dans le temps. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  Disque: le stockage local de la VM (par exemple /content) est temporaire et repart de zéro à chaque redémarrage. Augmenter votre quota Google Drive n’augmente pas cet espace local. Les offres payantes offrent davantage d’espace local que le palier gratuit, mais cet espace reste éphémère. Pour des copies robustes, travaillez depuis Drive ou copiez vos archives sur la VM puis décompressez localement pour limiter les lectures/écritures nombreuses. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  • Mesurer à chaud: vérifier la RAM disponible (!cat /proc/meminfo) et le disque (!df -h) en début de session.
  • High‑RAM: réserver Pro/Pro+ quand vos notebooks dépassent le profil standard.
  • Éviter les I/O fragmentées sur Drive: préférer une archive unique (.zip, .tar.gz) que vous extrayez sur /content. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))
  • Ne pas compter sur un “swap” pour tenir un dataset trop grand: privilégier l’échantillonnage, le streaming et les structures sur disque (par exemple memmap), ou basculer sur une VM dédiée si nécessaire.

  Free vs Pro/Pro+ : quelles différences concrètes ?

  Critère	Free	Pro	Pro+
  Compute units mensuelles	Non garanti	100	500
  Accès GPU/TPU	Limité, non prioritaire	Accès premium prioritaire	Accès premium prioritaire
  Mémoire système	Standard	Haute mémoire selon disponibilité	Haute mémoire selon disponibilité
  Arrière‑plan	Non	Non	Oui, jusqu’à 24 h si unités suffisantes
  Cas d’usage conseillés	Exploration, cours, POC légers	Prototypes exigeants, entraînements moyens	Entraînements longs, jobs asynchrones sur une journée

  Traduction pratique: Pro et Pro+ apportent des compute units et une priorisation d’accès aux accélérateurs plus rapides, ainsi qu’un profil mémoire plus généreux. Choisir Pro+ se justifie si vous avez besoin d’arrière‑plan jusqu’à 24 h ou d’un volume d’unités significativement supérieur. ([support.google.com](https://support.google.com/a/answer/13177581?hl=en))

  Exécution en arrière‑plan: que permet (ou pas) ?

  Disponible uniquement avec Pro+, l’arrière‑plan permet à un notebook déjà en cours d’exécution de continuer sans navigateur ouvert, jusqu’à 24 heures si votre solde d’unités le permet. Si l’exécution se termine (erreur, fin du script) ou si vous épuisez vos compute units, le backend s’arrête. Pour lever totalement les limites de durée, utilisez une VM dédiée sur Google Cloud ou Colab Enterprise. ([research.google.com](https://research.google.com/colaboratory/intl/en-GB/faq.html))

  • Bonnes pratiques: journaliser des checkpoints vers Drive ou le cloud, instrumenter la reprise, et notifier la fin de job.
  • À éviter: scripts “keep‑alive” fragiles. Mieux vaut structurer le code pour tolérer les redémarrages que tenter de contourner les politiques d’inactivité.
  • Besoins récurrents au‑delà de 24 h: orientez‑vous vers Vertex AI/VM GCP avec stockage persistant et planification.
  Apprendre à utiliser Python sur Google Colab

  Surveillance et optimisation des ressources

  Pour travailler efficacement en équipe sur Colab, il faut à la fois observer l’utilisation CPU/GPU/mémoire en temps réel et optimiser les entraînements pour tenir dans les quotas et stabiliser les sessions. Comme indiqué plus haut, choisissez et verrouillez un runtime cohérent pour tout le monde, puis ajoutez dès le début du notebook des cellules de vérification et de mesure afin de détecter rapidement les indisponibilités et les goulets d’étranglement.

  Comment monitorer CPU/GPU/mémoire ?

  • CPU, RAM, disque avec psutil: installez puis lisez l’utilisation du CPU, la mémoire disponible et l’espace disque pour repérer les saturations côté preprocessing et E/S.
  • GPU en ligne de commande: utilisez nvidia-smi avec --query pour extraire nom du GPU, mémoire totale/utilisée et taux d’utilisation, dans un format exploitable.
  • Vue synthétique avec gpustat: pratique pour un résumé coloré de l’état des GPUs, y compris l’utilisation CPU par processus.
  • Depuis les frameworks:
    • PyTorch: vérifiez l’accélérateur puis consultez la mémoire réservée/allocée (torch.cuda.memory_reserved/memory_allocated).
    • TensorFlow: listez les devices (tf.config.list_physical_devices('GPU')) et, si besoin, activez la croissance mémoire pour éviter les pré‑allocations massives.

    Exemple minimal de cellule de surveillance combinant psutil, nvidia-smi et PyTorch:

    Astuce rapide: pour une vue compacte côté shell, exécutez !gpustat --color --cpu. Pour automatiser, planifiez un snapshot toutes les n secondes en arrière‑plan et écrivez dans /content/metrics.csv afin de comparer les sessions.

    Comment optimiser l’entraînement (batch size, mixed precision) ?

    • Vérifier l’accélérateur avant tout: dans une cellule d’amorçage, testez torch.cuda.is_available() ou tf.config.list_physical_devices('GPU') et stoppez proprement si l’accélération n’est pas active.
    • Ajuster la taille de batch:
      • Montez progressivement jusqu’à la limite mémoire, reculez d’un cran dès le premier OOM pour garder une marge.
      • Besoin d’un batch effectif plus grand sans VRAM supplémentaire: utilisez l’accumulation de gradients (plusieurs micro‑batches avant optimizer.step()).
      • PyTorch AMP:

        from torch.cuda.amp import autocast, GradScaler
        scaler = GradScaler()
        for x, y in loader:
            optimizer.zero_grad(set_to_none=True)
            with autocast(dtype=torch.float16):
                y_hat = model(x)
                loss = criterion(y_hat, y)
            scaler.scale(loss).backward()
            scaler.step(optimizer); scaler.update()

      • TensorFlow:

        from tensorflow.keras import mixed_precision
        mixed_precision.set_global_policy("mixed_float16")

      • PyTorch DataLoader: num_workers adapté, pin_memory=True, persistent_workers=True, préfetch raisonné.
      • TensorFlow: tf.data avec prefetch, cache et map(num_parallel_calls=tf.data.AUTOTUNE).

      Conséquences à anticiper: une taille de batch plus grande améliore en général le débit et la stabilité des gradients, mais peut modifier la dynamique d’optimisation, ce qui peut exiger d’ajuster le taux d’apprentissage. La mixed precision réduit l’empreinte mémoire et accélère souvent les calculs, mais requiert une attention aux conversions de types et à l’échelle des pertes. Surveillez systématiquement la métrique métier, la stabilité numérique et les temps par itération après chaque changement pour valider le gain réel.

      Apprendre à utiliser Python sur Google Colab

      Sécurité des données sensibles

      Collaborer dans Colab implique de partager notebooks et données au sein de Drive. Les environnements étant temporaires et les notebooks facilement partageables, il faut dépasser les réflexes basiques. En bref: ne jamais mettre de secrets dans le code, centraliser la gestion des accès, tracer, et automatiser la rotation. Comme rappelé plus haut, quand vous manipulez des données sensibles, appliquez des partages Drive stricts et, si besoin, des contrôles IAM côté Google Cloud.

      • Éviter tout secret en clair dans notebooks, sorties de cellules, historiques et dépôts Git.
      • Charger les secrets au moment de l’exécution via variables d’environnement ou gestionnaire de secrets.
      • Isoler les espaces de stockage: Drives partagés par équipe et par classification de données.
      • Limiter les droits au strict nécessaire, journaliser, et planifier une rotation régulière des clés.
      • Sécuriser le chemin d’accès aux données: liens non publics, pas de partage “Quiconque avec le lien”.

      Où stocker les tokens et secrets ?

      • À proscrire: dans le notebook, dans un print(), dans un fichier poussé sur Git ou un dossier Drive largement partagé.
      • Préférer: variables d’environnement injectées à l’exécution, Google Cloud Secret Manager pour la conservation et la rotation, fichiers de configuration chiffrés.
      • Option locale encadrée: fichier .env chargé avec python-dotenv, stocké dans un dossier Drive privé non partagé à l’équipe si le secret est personnel, et ignoré par Git (.gitignore).
      • Pour générer des clés robustes: utiliser le module standard secrets de Python, puis stocker le résultat dans le gestionnaire de secrets, jamais dans le code.

      Conséquence en cas de mauvaise pratique: fuite accidentelle lors d’un partage de notebook, exposition via l’historique des versions, compromission de comptes tiers, et impact sur la conformité interne. Une clé exposée doit être révoquée et régénérée sans délai.

      Secret Manager et variables d’environnement: comment faire ?

      1. Créer le secret dans votre projet GCP: activer l’API Secret Manager, définir un secret (nom, libellés, version), donner aux membres ou au service d’exécution le rôle de lecture du secret.
      2. S’authentifier dans Colab: lancer l’authentification Google pour la session, ce qui autorise l’accès au projet.
      3. Installer le client Python puis lire le secret, le charger en variable d’environnement, et l’utiliser dans le code sans jamais l’afficher.
      4. Automatiser la rotation: planifier une rotation côté Secret Manager, adapter votre code pour toujours récupérer la dernière version.
      5. Alternative encadrée: pour des paramètres non sensibles, charger un .env privé. Pour des secrets, préférer Secret Manager ou un fichier chiffré avec KMS, jamais un .env en clair partagé.

      Exemple minimal dans Colab: authentifier, récupérer le secret, l’injecter dans l’environnement, puis l’utiliser. Rien n’est imprimé.

      Bon à savoir: l’environnement Colab est recréé à chaque session. Centraliser les secrets dans Secret Manager évite de les recopier et facilite la révocation. Pour générer un secret fort côté Python: import secrets; secrets.token_urlsafe(32), puis l’enregistrer dans le gestionnaire, pas dans le notebook.

      Principes de moindre privilège et DLP Drive

      • Limiter les scopes et rôles: IAM au plus juste, pas d’Owner global. Pour les API Drive et BigQuery, sélectionner uniquement les autorisations nécessaires au notebook.
      • Cloisonner par besoin métier: un Drive partagé par équipe et par sensibilité, avec lecteurs, commentateurs et éditeurs distincts. Désactiver le partage par lien public.
      • Appliquer des règles DLP Drive: détecter N° de carte, IBAN, identifiants personnels, et bloquer le partage externe ou l’impression selon la politique.
      • Journaliser et auditer: activer les logs d’accès, passer en revue périodiquement les permissions et les partages inhabituels.
      • Réduire l’exposition: créer des jeux de données dérivés sans identifiants, masquer ou pseudonymiser avant de partager avec un large public.

      En pratique: démarrez par une classification simple des données, créez des Drives partagés alignés sur cette classification, définissez des groupes Google distincts pour l’accès, puis activez des règles DLP ciblées. Testez vos notebooks avec des comptes au profil minimal pour vérifier que rien d’inutile n’est accordé. Si un partenaire externe participe, préférez un Drive dédié avec accès limité et expiration automatique des partages.

      Approfondir IAM, Secret Manager et DLP sur Google Cloud

      Dépannage: que faire en cas de panne ?

      Quand un notebook Colab bloque, adoptez une démarche simple: observer le symptôme, confirmer le diagnostic avec 2 ou 3 commandes, appliquer une procédure courte et vérifiée. Les sections ci‑dessous proposent des checks rapides et des remèdes concrets pour repartir vite sans perdre de travail.

      Erreurs mémoire (OOM): que faire ?

      • Vérifier la mémoire utilisée:

        !free -h              # RAM
        !df -h                # Disque
        !nvidia-smi           # VRAM GPU si GPU activé

      • Réduire l’empreinte: diminuer batch_size, dimension d’entrée, longueur de séquence, nombre de workers du DataLoader, taille des buffers.
      • Nettoyer explicitement:

        # PyTorch
        import gc, torch
        del variables_non_utiles
        gc.collect()
        torch.cuda.empty_cache()  # libère le cache de l’allocateur
        
        # TensorFlow
        import tensorflow as tf, gc
        del variables_non_utiles
        gc.collect()

      • Activer la précision mixte ou le half‑precision selon le framework:

        # PyTorch
        from torch.cuda.amp import autocast, GradScaler
        scaler = GradScaler()
        with autocast():
            loss = model(inputs).loss
        
        # TensorFlow/Keras
        from tensorflow.keras import mixed_precision
        mixed_precision.set_global_policy('mixed_float16')

      • Segmenter le calcul: gradient checkpointing, accumulation de gradients, découpage du dataset en sous‑lots.
      • Externaliser des étapes lourdes: prétraitements sur CPU, cache sur disque, échantillonnage.
      • Dernier recours: redémarrer le runtime puis relancer uniquement la cellule “setup” et la portion de code nécessaire.

      Pourquoi mon GPU/TPU n’est pas détecté ?

      • Confirmer le type d’exécution: Exécution > Modifier le type d’exécution > Accélérateur matériel > GPU ou TPU. Reconnecter si Colab le propose.
      • Tests rapides dans une cellule:

        # GPU côté système
        !nvidia-smi
        
        # PyTorch
        import torch
        print(torch.cuda.is_available())
        
        # TensorFlow
        import tensorflow as tf
        print(tf.config.list_physical_devices('GPU'))
        print(tf.config.list_logical_devices('TPU'))

      • Après installation ou changement de versions, redémarrer l’environnement: Exécution > Redémarrer l’environnement. Colab charge un Python propre à chaque session, pensez à relancer la cellule d’installation (%pip) au début du notebook.
      • Compatibilité CUDA et frameworks: sur Colab, vous ne choisissez pas le driver. Installez des builds compatibles du framework avec le CUDA du runtime. Exemple d’approche:

        # Identifier la version CUDA visible côté runtime
        !nvidia-smi | head -n 15
        
        # Installer un framework compatible (exemples génériques)
        %pip -q install --upgrade pip
        # PyTorch: choisir l’index correspondant au CUDA de la machine
        # %pip -q install torch torchvision --index-url https://download.pytorch.org/whl/cu118
        # TensorFlow: utiliser une version GPU compatible, ou CPU-only pour valider l’environnement
        # %pip -q install "tensorflow==<version_compatible>"

      • Ressource indisponible: si le message indique que le GPU ou le TPU est temporairement indisponible, réessayez plus tard, libérez et relancez la session, ou passez à une offre prioritaire.

      Quand redémarrer le runtime et Drive ?

      Redémarrez l’environnement quand vous observez des import incohérents après installation, des erreurs système liées à des bibliothèques natives, des OOM répétés malgré la réduction mémoire, un GPU non détecté après modification de versions, ou après un apt-get important.

      • Redémarrer proprement: Exécution > Redémarrer l’environnement, puis relancer la cellule “setup” (%pip) au début du notebook.
      • Remonter Drive si besoin:

        from google.colab import drive
        drive.mount('/content/drive')

      • Impacts: la mémoire est vidée, les fichiers temporaires sous /content disparaissent, les fichiers sur Drive restent intacts. Pensez à sauvegarder vos sorties utiles vers Drive avant le redémarrage.

      Diagnostic rapide: journaux, factory reset runtime

      • Lire les messages d’erreur dans la sortie de cellule: repérer la première trace utile, pas seulement la dernière ligne.
      • Confirmer un kill OOM Linux ou un souci GPU:

        !dmesg | tail -n 50
        !nvidia-smi

      • Photographier l’état logiciel:

        !python -V
        !pip list | sort | tail -n 30
        !uname -a

      • Vérifier l’espace disque si les téléchargements échouent:

        !df -h

      • “Factory reset runtime”: Exécution > Factory reset runtime. Effets: VM réinitialisée, paquets installés et fichiers de /content supprimés, Drive démonté. Précautions: sauvegarder dans Drive avant, puis remonter Drive et réexécuter la cellule d’installation.

      Conflits de versions: pip uninstall/reinstall, compatibilité CUDA

      1. Identifier le conflit: lire l’erreur, exécuter %pip check, lister les versions installées.
      2. Nettoyer:

         %pip -q install --upgrade pip
         %pip -q uninstall -y paquet_conflitant_1 paquet_conflitant_2
         %pip -q cache purge

      3. Réinstaller de façon reproductible: centraliser dans une cellule unique en début de notebook, préférer %pip à !pip, pinner les versions.

         %pip -q install -r "/content/drive/My Drive/projet/requirements.txt"

      4. Choisir des builds compatibles GPU si nécessaire: installer des roues PyTorch ou TensorFlow qui correspondent au CUDA visible dans nvidia-smi. À défaut, tester une version CPU pour valider le code.
      5. Redémarrer l’environnement après des installations natives importantes, puis valider:

         import torch, tensorflow as tf
         print(getattr(torch, "__version__", "no-torch"))
         print(getattr(tf, "__version__", "no-tf"))

      6. Geler et partager:

         !pip freeze > requirements.txt
         # Déposer le fichier dans Drive ou le repo et l’utiliser partout

      Apprendre à utiliser Python sur Google Colab

      Bonnes pratiques pour un projet d’équipe

      En équipe, visez un projet reproductible, lisible et sécurisé. Sur Colab, cela passe par une structure de dossiers commune, un script d’initialisation idempotent, des règles de revue de code claires et une automatisation minimale reliée à GitHub. Les environnements Colab étant temporaires, centralisez l’installation des dépendances et l’accès aux données, puis automatisez les vérifications de qualité.

      Quelle structure de dossiers pour l’équipe ?

      Adoptez un squelette standard réutilisable par toutes vos équipes, avec des chemins identiques pour éviter les “ça marche chez moi”.

      • data/raw: sources brutes en lecture seule
      • data/processed: jeux de données nettoyés ou features
      • notebooks: exploration et rapports (garder léger)
      • src: modules Python réutilisables (.py)
      • conf: paramètres du projet, gabarits .env.example
      • models: artefacts d’entraînement, checkpoints
      • reports: figures et sorties prêtes à partager
      • _cache: caches partagés (pip, modèles, datasets)

      Exemple minimal avec un Drive monté, même chemin pour toute l’équipe:

      Conseil sécurité: ne versionnez jamais de secrets. Gardez .env.example dans le repo et le vrai fichier .env privé sur Drive, avec des droits d’accès restreints.

      Quel script de setup et de cache prévoir ?

      Objectif: une cellule de setup idempotente qui prépare l’environnement, monte Drive, crée l’arborescence et configure les caches. Rappel Colab: préférez %pip à !pip et regroupez les installations dans une seule cellule.

      1. Monter Drive et définir les chemins racine du projet.
      2. Créer les dossiers standards s’ils n’existent pas.
      3. Configurer les caches persistants sur Drive: pip, modèles et datasets.
      4. Charger les variables d’environnement locales si vous en utilisez (ex: python‑dotenv).
      5. Installer les dépendances via un requirements.txt commun et figé.
      6. Vérifier l’accélérateur attendu et les versions clés.

      Bonnes pratiques cache: stockez vos caches sur Drive pour éviter de tout retélécharger à chaque session, surtout pour les modèles et datasets volumineux. Nettoyez périodiquement les caches partagés pour contenir l’espace disque.

      Comment organiser la revue de code ?

      • Code métier dans src/ (.py), notebooks légers orientés démo et analyse.
      • Pairer les notebooks avec des scripts texte pour des PR lisibles (ex: Jupytext). Les revues portent alors sur des .py, pas sur du JSON.
      • Déterminisme: fixer les graines aléatoires et documenter l’ordre d’exécution.
      • Qualité: lint + formatage + tests unitaires avant toute PR.
      • Données: utiliser des échantillons anonymisés en data/raw pour les revues, jamais de données sensibles en pièces jointes aux PR.

      Checklist PR: exécution du notebook de démonstration sans erreur, black --check, ruff ou flake8 propres sur src/, pytest vert, et description claire des jeux de données utilisés.

      CI/CD et automatisation: que peut-on faire avec Colab ?

      • Exporter vers GitHub: Fichier > Enregistrer une copie dans GitHub, puis ouvrir une PR.
      • Git depuis Colab: cloner le repo, travailler sur une branche, puis git push avec un token saisi à la volée (ne pas le stocker dans le notebook).
      • Tests en workflows externes: GitHub Actions exécute lint et tests sur src/; optionnellement exécuter un notebook de “smoke test” avec nbclient ou papermill côté runner.
      • Validation des notebooks: contrôler que la cellule de setup s’exécute et que les sorties clés sont produites, sans dépendre d’un GPU spécifique pour le CI.

      Cas concret: chaque membre travaille dans un notebook personnel dans notebooks/ et pousse les fonctions stables dans src/. Une PR met à jour requirements.txt si nécessaire. Les Actions vérifient formatage, lint et tests, puis un petit notebook de “smoke test” valide la cellule de setup. Les artefacts entraînés sont sauvegardés dans models/ sur Drive, avec un nommage versionné.

      Apprendre à utiliser Python sur Google Colab

      Visualisation et suivi des expériences

      En projet d’équipe à distance, un notebook Colab combine code et texte Markdown pour documenter, relire et itérer rapidement. Pour garder le cap, centralisez la visualisation des résultats et le suivi des entraînements dans des tableaux de bord partagés sur Google Drive, afin que chacun puisse comparer des runs, expliquer les écarts et décider des prochains essais.

      • Suivre les métriques en temps réel: perte, précision, F1, AUC, temps par époque.
      • Tracer l’historique des runs et des hyperparamètres, avec un chemin de logs commun sur Drive.
      • Partager des résultats interactifs: graphiques cliquables pour l’exploration, cartes pour les données géographiques.
      • Mettre en place des dashboards légers: TensorBoard pour le monitoring, Plotly pour les graphiques riches, Folium pour les cartes.

      TensorBoard dans Colab: comment l’activer ?

      1. (Recommandé) Montez Google Drive pour rendre les journaux persistants entre les sessions.

         from google.colab import drive
         drive.mount('/content/drive')
         log_dir = "/content/drive/My Drive/projet/logs"

      2. Écrivez les logs pendant l’entraînement.
         • TensorFlow/Keras: ajoutez le callback TensorBoard.

         import tensorflow as tf
         tb_cb = tf.keras.callbacks.TensorBoard(log_dir=log_dir, histogram_freq=1)
         model.fit(X_train, y_train, epochs=5, validation_data=(X_val, y_val), callbacks=[tb_cb])

         • PyTorch: utilisez SummaryWriter.

         from torch.utils.tensorboard import SummaryWriter
         writer = SummaryWriter(log_dir)
         for epoch in range(5):
             # train...
             writer.add_scalar("loss/train", train_loss, epoch)
             writer.add_scalar("acc/val", val_acc, epoch)
         writer.close()

      3. Chargez l’extension TensorBoard puis lancez l’onglet dédié dans la sortie du notebook.

         %load_ext tensorboard
         %tensorboard --logdir "$log_dir" --reload_interval 5

         La vue TensorBoard intégrée permet de naviguer entre Scalaires, Graphes, Images et HParams, et se met à jour automatiquement quand de nouveaux événements sont écrits.
      4. Astuce d’équipe: créez un sous-dossier par run (timestamp ou nom de branche) pour comparer plusieurs entraînements dans la même interface.
      5. Si besoin, nettoyez les anciens journaux pour éviter les collisions de runs, puis relancez la cellule %tensorboard.

      Bonnes pratiques: gardez un log_dir stable et partagé, pinnez les versions de vos bibliothèques dans un requirements.txt commun, et documentez dans le notebook les hyperparamètres clés par run pour faciliter la relecture asynchrone.

      Graphiques interactifs (Plotly, Folium): quand les préférer ?

      Pour des rapports statiques et rapides, Matplotlib ou Seaborn suffisent souvent. Dès que vous devez partager un résultat cliquable avec des non‑développeurs ou explorer des points individuellement, préférez Plotly: sur Colab, les figures s’affichent directement dans la cellule et peuvent être exportées en HTML dans Drive pour un partage simple. Pour des données géographiques, Folium s’appuie sur Leaflet pour créer des cartes interactives avec tuiles, calques et popups, idéal pour visualiser des zones, des heatmaps ou des localisations de prédictions. L’approche est naturelle dans Colab et se marie bien avec des jeux de données stockés sur Drive; les cartes générées peuvent aussi être enregistrées en HTML.

      Cas concret: votre équipe compare plusieurs entraînements d’un classificateur. Avec Plotly, vous tracez les pertes train/val de chaque run, survolez pour lire les valeurs exactes et filtrez les courbes à la volée, puis enregistrez le rapport interactif (fig.write_html) dans le dossier commun sur Drive pour relecture. Autre scénario: un projet de détection d’anomalies géolocalisées. Avec Folium, vous affichez vos points scorés sur une carte, ajoutez un calque par seuil et partagez le fichier HTML aux parties prenantes qui peuvent explorer la carte dans leur navigateur.

      Apprendre à utiliser Python sur Google Colab

      En résumé

      Pour réussir un projet d’équipe sur Google Colab, validez dès le départ cinq décisions clés: le type de runtime, la stratégie d’import des données, la gestion des dépendances, les règles de sécurité et le mode de collaboration. Cela évite les incompatibilités, sécurise l’accès aux jeux de données et fluidifie l’exécution partagée des notebooks.

      • Runtime (CPU/GPU/TPU): démarrez sur CPU pour l’exploration et la préparation, basculez sur GPU pour l’entraînement profond, testez TPU avec TensorFlow ou JAX si pertinent. Figez ce choix pour tout le projet et ajoutez une cellule de vérification de l’accélérateur. Rappel utile: un notebook ne peut être exécuté activement que par une personne à la fois, planifiez les runs lourds ou dupliquez le notebook par membre puis fusionnez.
      • Données (imports et chemins): petit fichier public: BytesIO/requests ou gdown. Fichiers publics multiples: gdown sur un dossier. Données privées d’équipe: Drive monté avec un chemin commun (raccourci partagé). Volumes importants ou pipelines récurrents: GCS et BigQuery. Documentez un chemin unique par source et évitez d’exposer des secrets dans le notebook.
      • Environnement (dépendances): centralisez l’installation au début du notebook avec %pip, réservez apt-get aux paquets système, pinner les versions dans un requirements.txt partagé et réutilisé en CI. Redémarrez le runtime après des installations lourdes. Restez simple: pip + requirements.txt pour la majorité des cas, conservez micromamba/conda uniquement si nécessaire.
      • Sécurité et gouvernance: partagez les notebooks et dossiers Drive au plus juste (lecture/édition), évitez le public par défaut. Pour des données sensibles ou des besoins de contrôle renforcé, combinez Drive avec des droits fins ou passez sur des notebooks managés Google Cloud et Vertex AI avec IAM.
      • Collaboration et productivité: nommez clairement les fichiers, versionnez notebooks et requirements.txt, utilisez les commentaires et l’historique Drive. Pour un travail très synchrone, dupliquez par personne puis consolidez. Les fonctionnalités d’assistance par IA aident à générer, expliquer et transformer le code pour accélérer les itérations.
      Apprendre à utiliser Python sur Google Colab

      Pour aller plus loin

      Besoin d’aller au‑delà du démarrage rapide sur Colab, de vérifier la compatibilité TensorFlow ou PyTorch avec les accélérateurs, ou de cadrer la sécurité côté Google Cloud, tout en disposant d’exemples de notebooks prêts à l’emploi ? Voici une sélection de ressources officielles et fiables pour gagner du temps et limiter les erreurs.

      Documentation officielle Colab

      • Page d’accueil Colab et galerie de notebooks: colab.research.google.com (ouvrir, créer, rechercher des exemples).
      • Guides et nouveautés développeurs: developers.google.com/colab (présentation des fonctionnalités, accélérateurs, bonnes pratiques).
      • FAQ et prise en main: research.google.com/colaboratory/faq.html (quotas, sessions, stockage, partage Drive).

      Compatibilité frameworks et accélérateurs

      • TensorFlow sur GPU: tensorflow.org/install/gpu et guide de l’exécution sur GPU: tensorflow.org/guide/gpu.
      • TPU avec TensorFlow ou JAX: tensorflow.org/guide/tpu et guide JAX sur TPU: cloud.google.com/tpu/docs/jax-quickstart.
      • PyTorch et CUDA: matrice de compatibilité et notes CUDA: pytorch.org/docs/stable/notes/cuda.html.
      • PyTorch sur TPU avec XLA: pytorch.org/xla (installation, exemples, limites connues).

      Sécurité et gouvernance sur Google Cloud

      • Contrôles d’accès: cloud.google.com/iam/docs/overview (rôles, principes du moindre privilège, comptes de service).
      • Protection des données sur Cloud Storage: cloud.google.com/storage/docs/security/overview (chiffrement, clés, CMEK, journaux).
      • Périmètres de sécurité et exfiltration: cloud.google.com/vpc-service-controls/docs (isoler des projets et services sensibles).
      • Bonnes pratiques Vertex AI et notebooks managés: cloud.google.com/vertex-ai/docs/general/security (configurations d’entreprise, réseau et données).

      Exemples de notebooks modèles

      • Tutoriels TensorFlow avec bouton Exécuter dans Colab: tensorflow.org/tutorials (vision, NLP, entraînement et export).
      • Tutoriels PyTorch avec liens Colab: pytorch.org/tutorials (classifieurs, vision, texte, optimisation).
      • BigQuery dans les notebooks: magics et SDK Python pour l’analyse: cloud.google.com/bigquery/docs/visualize-jupyter.
      • Google Earth Engine dans Colab: installation et exemples cartographiques: developers.google.com/earth-engine/guides/python_install-colab.

      Astuce pratique pour votre équipe: ajoutez dans le README du projet un court tableau de liens vers ces pages et précisez la version minimale des bibliothèques utilisées. Vous réduirez les écarts d’environnement et accélérerez l’onboarding des nouveaux contributeurs.

      Apprendre à utiliser Python sur Google Colab