Tester SharePoint dans des conditions réelles grâce à des documents fictifs

Lorsqu’on travaille sur un projet SharePoint, tout semble souvent fonctionner parfaitement… jusqu’au jour où les utilisateurs commencent réellement à déposer des documents. Les bibliothèques se remplissent, les vues ralentissent, certains flux Power Automate se déclenchent en cascade, et des problèmes apparaissent là où personne ne les avait anticipés. C’est précisément pour éviter ce genre de surprise que le script s’avère particulièrement utile.

Une bibliothèque SharePoint vide est trompeuse. Elle se charge instantanément, les vues sont propres, la navigation est fluide. Or, ces conditions ne reflètent jamais la production. Dès que l’on dépasse quelques centaines de documents, SharePoint change de comportement :
la navigation devient plus complexe, les vues doivent être filtrées correctement et certaines limites bien connues, comme celle des 5 000 éléments commencent à entrer en jeu.

C’est dans ce contexte que générer du contenu fictif mais réaliste devient une étape essentielle du cycle de test.

Le script repose sur une idée très pragmatique :
partir d’un seul fichier modèle (par exemple un document Word vide) et le copier autant de fois que nécessaire dans une bibliothèque SharePoint, en lui donnant à chaque fois un nom unique. Le tout est automatisé via PnP PowerShell, ce qui permet de créer en quelques secondes ou minutes ce qui prendrait autrement des heures à la main.

L’objectif n’est pas de tester le contenu des documents, mais le comportement de SharePoint face au volume.

À quoi cela ressemble concrètement ?

Sur la capture, on voit clairement l’intérêt du script :
la bibliothèque n’est plus vide, elle ressemble enfin à un espace de travail réel. Les dossiers se succèdent, les fichiers portent des noms uniques, et l’ensemble permet de tester la navigation, les vues et les performances dans des conditions proches de la production.

Deux scénarios réels couverts par le script

Le script a été pensé pour s’adapter aux usages courants en entreprise.

Dans un premier scénario, il est capable de créer un grand nombre de fichiers directement dans une bibliothèque ou un dossier donné. C’est idéal pour tester les vues SharePoint, les tris, les filtres et les regroupements sur de gros volumes.

Dans un second scénario, il crée un dossier par document, puis ajoute un fichier à l’intérieur. Cette approche est très proche de ce que l’on retrouve dans des bibliothèques projets, clients ou dossiers métiers, où chaque affaire possède son propre conteneur.

Ces deux modes permettent déjà de couvrir la majorité des besoins de test.

Voici donc le script en question :

#Global Variable Declaration

$pnpPowerShellModule = Get-Module PnP.PowerShell
if ($null -eq $pnpPowerShellModule) {
    Install-Module PnP.PowerShell
}

#Global Variables 
$SiteURL = "https://yourdomain.sharepoint.com/sites/mytestsite" 

#Serverrelative url of the Library, this will be used for Folder scenario
$SiteRelativeURL= "/sites/mytestsite/Shared Documents"

#Local file path where a single dummy document is available

$File= "D:\SP\repos\myscriptsamples\Dummy.docx"

#This can be used for file scenario and provide the folder path where we want to create files, it can be subfolder also
$Folder="Shared Documents"

#Read Information to get which operation need to perform
$MethodCall=Read-Host "Which Function Do you Need to Invoke ? Folder or File" 
$MethodCall=$MethodCall.ToUpper() 

#This will be max count of dummy folder or files which we have to create
$maxCount = 5


#For Sample Document Creation the file needs to be part of some location.
$FilePath= Get-ChildItem "D:\SP\repos\myscriptsamples\Dummy.docx"
$FileName = $FilePath.BaseName #Inorder to get the filename for the manipulation we used this function(BaseName)

#For Logging the Operations
$LogTime = Get-Date -Format "MM-dd-yyyy_hh-mm-ss"
$LogFile = 'D:\SP\repos\myscriptsamples\'+"FileFolderCreation_"+$LogTime+".txt"
 

 if($MethodCall -eq "FOLDER" -or $MethodCall -eq "FILE")
 {

 Try 
{
    #Connect to PnP Online
    Connect-PnPOnline -Url $SiteURL -UseWebLogin
    #To Create Folder and Files  
    if($MethodCall -eq "FOLDER")
    {
    	$FolderCnt=0
    	while($FolderCnt -lt $maxCount)
    	{
		    $FolderName= $FileName +"_"+ $FolderCnt
			write-host $FolderName
		    $SiteRelativePath=$SiteRelativeURL+"/"+$FolderName
			write-host $SiteRelativePath
		    Try
		    {
			    Add-PnPFolder -Name $FolderName -Folder $SiteRelativeURL -ErrorAction Stop
			write-host $SiteRelativePath

                Add-PnPFile -Folder $SiteRelativePath -Path $File
			   
		    }
		    catch 
		    {
    		    write-host "Folder Creation Error: $($_.Exception.Message)" -foregroundcolor Red
		    }
            $FolderCnt++
    	}
       
        write-output "New Folder and Files Created '$FolderName' Added! $($env:computername)" >> $LogFile 
         Write-host -f Green "Script execution completed...." |Out-File $LogFile -Append -Force 
          write-output "Script execution completed.... $($env:computername)" >> $LogFile -f Green
    }

    #To Create Files alone
    if($MethodCall -eq "FILE")
    {
	    $FileCnt=0
	    while($FileCnt -lt $maxCount)
	    {
		    $NewFileName= $FileName+"_"+$FileCnt+".docx"
		    try
		    {
			    Add-PnPFile -Path $File -Folder $Folder -NewFileName $NewFileName
		    }
		    catch
		    {
			    write-host "Error: $($_.Exception.Message)" -foregroundcolor Red
		    }
		    $FileCnt++
		    Write-host -f Green "New File Created '$NewFileName' Added!" |Out-File $LogFile -Append -Force 
            write-output "New File Created '$NewFileName' Added! $($env:computername)" >> $LogFile -f Green
    
	    }
            Write-host -f Green "Script execution completed...." |Out-File $LogFile -Append -Force 
            write-output "Script execution completed.... $($env:computername)" >> $LogFile -f Green
    }
}
catch 
{
    write-host "Error: $($_.Exception.Message)" -foregroundcolor Red
}

 }
 else{
 write-host "Please type either File or Folder" -foregroundcolor Red
 }

Avec une bibliothèque remplie artificiellement mais intelligemment, il devient possible de :

• tester les performances avec plusieurs milliers de documents
• valider les vues SharePoint avant mise en production
• observer le comportement réel de flux Power Automate
• préparer des démonstrations crédibles pour les utilisateurs
• détecter des problèmes bien avant le go‑live

En pratique, ce type de test évite de nombreuses retouches tardives, souvent coûteuses.

Il est important de le souligner :
les documents créés sont volontairement simples.

Ils partagent le même contenu, n’ont pas de métadonnées avancées et ne simulent pas de logique métier. Et c’est très bien ainsi : le script se concentre uniquement sur le volume et la structure, pas sur les processus. Pour des besoins plus poussés (versions, métadonnées, validation), d’autres scripts PnP existent et peuvent compléter celui‑ci. Le script fait partie de ces outils qui ne font pas de bruit, mais qui améliorent radicalement la qualité d’un projet SharePoint. Il permet de tester sérieusement, de rassurer les équipes et d’éviter les mauvaises surprises une fois les utilisateurs actifs. Dans un contexte Microsoft 365 moderne, une bonne préparation passe aussi par du faux contenu bien utilisé.